nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OD failure/rollback

mogoo

Scenario, example directories /foo/bar/...
1. /bar/ directory is NOT managed in teamsite and has 200,000 files
2. /foo/ files are managed in teamsite
3. target server is actually 3 blades

We're attempting a directory-based deploy of /foo/, with do-deletes and exclude of /bar/. The deploy takes 4 hours, then does a rollback. /bar/ doesn't exist in teamsite, so why is it taking so long, and how can we fix this?

Find more posts tagged with

Comments

Adam Stoller

is bar being excluded on *both* the source *and* target side of the deployment?
What version of OD are you using?
What is the OS platform? (I'm not sure what "3 blades" means)
How much content (# files, amount of disk space) is in the /foo directory ignoring the /foo/bar subdirectory contents?
How many legs in this deployment?
I'm assuming this is a transactional deployment - yes?
Can you post the configuration file?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

mogoo

Sorry, here's more details, and I've attached the config...
OD 5.6.0.1, Solaris
Yes, it's a transactional deployment.
Yes, the exclude is both on source and target of deployment.
"Blades" mean it's a deployment to 3 servers.
There's only about 12 files in /foo/.

This took 6 hours to run yesterday, and failed/rolled back. However, it appears to have only rolled back on the first server - the 2nd & 3rd "blades" have the new files.

It looks like it's taking so long because it seems that OD is looking through the excluded directory of 200,000 files, even though we told it to exclude. And that's gumming everything up. If we could get it simply to ignore the excluded directory, I think we'd be fine.

TIA!
maureen

nipper

I do not see any exclude in the sender, but that should not be an issue.

I assume there is a directory under education on the receiver but not on the sender.

I saw this behavior change from OD 5.5 to 5.6, when I deployed (date different) from
my config branch to iw-home. Deployment time went much higher since it walked through
iw-home saying Delete iw-bin...No.... in the logs.

I found it easier to go to a file list deployment in my case.

Andy

mogoo

Thanks Andy. Wow, that's not good. We want to be able to do directory based deploys with doDeletes. Any idea if this "walk thru" behavior changes in OD 6.0 or beyond?

Adam Stoller

I dont see ANY exclusions on either the source or target sides in the deployment configuration file you put up here.
But like Andy, I too believe that OD may be taking longer to process excluded and/or not-to-be-deleted files. If I can find time to pin it down I will - but if anyone else has some data points on this and opens a case - please remember to post the bug or feature request ID along with a description of the issue.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

mogoo

Duh... I've posted the wrong version. Here's the one with the excludes in it. Sorry. But if OD 5.6 just takes longer to process excluded dirs, then the point is moot.

Hopefully this is corrected in OD 6 -- we're about a month away from finding out. If it's not corrected, we'll open a case.

Thanks for your inputs!
maureen

Adam Stoller

Clearly you are using the OD Admin GUI to create your config files - may I suggest that you try editing this config file by hand and change it from: ...
<replicationFarmSet >
<replicationFarm name="Webfarm" >
<nodeRef useNode="PerseusHost" >
<targetRules area="" >
<filters >
<excludePath subPath="teacherartexchange/archive" >
</excludePath>
</filters>
</targetRules>
</nodeRef>
<nodeRef useNode="TheseusHost" >
<targetRules area="" >
<filters >
<excludePath subPath="teacherartexchange/archive" >
</excludePath>
</filters>
</targetRules>
</nodeRef>
<nodeRef useNode="HeraclesHost" >
<targetRules area="" >
<filters >
<excludePath subPath="teacherartexchange/archive" >
</excludePath>
</filters>
</targetRules>
</nodeRef>
</replicationFarm>
</replicationFarmSet>
<definition name="education_to_Webfarm" >
<source >
<sourceFilesystem area="/default/main/GettyPublic/STAGING" filelist="" >
<pathSpecification >
<path name="education" >
<filters>
<excludePath subPath="teacherartexchange/archive" >
</excludePath>
</filters>
</path>
</pathSpecification>
</sourceFilesystem>
</source>
<target useReplicationFarm="Webfarm" >
<targetFilesystem area="/data1/web/getty/education" >
</targetFilesystem>
<comparisonRules dateDifferent="yes" revert="no" ignoreAcls="no" ignoreModes="yes" ignoreUser="no" ignoreGroup="yes" >
</comparisonRules>
<transferRules doDeletes="yes" dontDo="no" preserveAcls="no" followLinks="no" svrTryCount="" svrTryInterval="" svrTryDisableOverwrite="no" rmReadOnly="no" >
</transferRules>
<permissionRules amask="" omask="" directory="0755" file="0755" group="webprod" user="webprod" changeAccess="" setAccess="" >
</permissionRules>
</target>
</definition>
...to:...
<replicationFarmSet >
<replicationFarm name="Webfarm" >
<nodeRef useNode="PerseusHost"/>
<nodeRef useNode="TheseusHost"/>
<nodeRef useNode="HeraclesHost"/>
</replicationFarm>
</replicationFarmSet>
<definition name="education_to_Webfarm" >
<source >
<sourceFilesystem area="/default/main/GettyPublic/STAGING">
<pathSpecification >
<path name="education"/>
<filters>
<excludePath subPath="teacherartexchange/archive"/>
</filters>
</pathSpecification>
</sourceFilesystem>
</source>
<target useReplicationFarm="Webfarm" >
<targetFilesystem area="/data1/web/getty/education"/>
<comparisonRules dateDifferent="yes" ignoreModes="yes" ignoreGroup="yes"/>
<transferRules doDeletes="yes"/>
<permissionRules directory="0755" file="0755" group="webprod" user="webprod"/>
<filters>
<excludePath subPath="teacherartexchange/archive"/>
</filters>
</target>
</definition>
...and see if that helps. I'm especially curious as to why the config file had the source-side filters embedded within the <path> element since I thought the <path element stopped being a container in 5.5.1? The other big change is to move the target-side filters from being redundant entries on each target node to being global in the target-section of the definition.
Anyway, see if the above changes make it work better - if so, you can probably open a case with Support....

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com