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; } } }

Fanout and customer-teamsite-resource-config.xml

Adam Stoller

Environment[indent]TS/SP/LS/OD 7.2.1 on Linux with WebSphere[/indent]Topic[indent]Trying to figure out how to configure things for an environment that includes:

The goal is to deploy the correct files from the correct folders for the correct site to the correct target location on the correct servers (correct? :-)) My question is - did I figure it out?(I'm hoping to soon have sufficient servers setup where I can begin to play with this - but I prefer to know I'm on the right track rather than wasting multiple hours if not days or weeks going down the wrong path.If I'm write about the second approach - I should be able to simplify my farms into just WEB_FARM and APP_FARM with no SITE# prefix - because we're always going to be deploying to the same nodes in both cases - just to different directories.Another Question: Does the above have any affect on how / how-often / when / whatever the LSCS deployments? or are they two distinct mechanisms?

Find more posts tagged with

Comments

Rick Poulin

[QUOTE=ghoti]

It's affected big time. Here's the problem: The above is all theory that doesn't actually farking work until 7.3. In 7.2, the LSCS deployment barfs all over your face if it sees entries that aren't =~ /$(development|production)^/. It's listed as resolved issue "RTR-1348" in the 7.3 release notes. There may be a patch for 7.2.1. I've accomplished a subset of what you need on 7.2 with unsupported hacks and a roadmap to getting back on the supported track post 7.3-upgrade, but it ain't pretty.TL;DR, you're **** out of luck if support can't provide you with a patch.

Adam Stoller

Rick,

I think I'm working my way through your 100 answers :-) Thanks much for the insight - I'm dreading having to tell the customer we need to upgrade to do what they want (when their "go live" date is only a couple a months away...) but we'll see.

Along those lines - where must I [currently] preserve "development" and "production"? Is that for $targetNodes in the WFM (via SCRIPT(DeployFilesTargetNodes)) or targetNode in

customer-teamsite-resource-config.xml

or somewhere else?

I like the idea of shifting the split between WEB and APP into the (copy of) OpenDeployWebRoot.xml. On that front - I don't see anything in the workflow where the name of the deployment configuration file is specified. Does that mean that the name is hard-coded somewhere and I have to back-up the original before modifying it rather than creating a variant copy?

Adam Stoller

I'd sooner set targetnode=SITE1 and then modify OpenDeployWebRoot.xml to have an additional with target repFarms "$TargetNode^_WEB" and "$TargetNode^_APP".

How would I pass in distinct targetArea's then?
I can think of a couple of ideas:

"/>But then I'd need to do something similar with respect to the filterPatterns too - yes?This is just starting to sound nearly as complicated - with the only (and possibly good) advantage being that, if made to work, it would give you a transactional aspect to both web and app servers together.

Rick Poulin

Along those lines - where must I [currently] preserve "development" and "production"? Is that for $targetNodes in the WFM (via SCRIPT(DeployFilesTargetNodes)) or targetNode in customer-teamsite-resource-config.xml or somewhere else?

They must be preserved in the customer-teamsite-resource-config.xml, and by extension, in your TargetNodes task variable. You can safely add entries in the XML and not use them in your WF, but then what's the point?

I like the idea of shifting the split between WEB and APP into the (copy of) OpenDeployWebRoot.xml. On that front - I don't see anything in the workflow where the name of the deployment configuration file is specified. Does that mean that the name is hard-coded somewhere and I have to back-up the original before modifying it rather than creating a variant copy?

This is "hard-coded" as a Spring-configurable parameter in OOTB XML configs. You can use a different ODConf via your customer-teamsite-resource-config.xml by either overriding the existing bean, or creating your own and adding it to the set of deployment descriptors. You'll have to look in AppContainer/server/default/deploy/iw-cc.war/WEB-INF/conf/livesite/resources/*.xml to see what's existing. Here's a sample that clones the HeadlessDeploymentTask from the PLC to sub in a different ODConf, and ignore all default deployment descriptors (because merge=false).

[PHP]

class="com.interwoven.livesite.workflow.task.DeploymentTask">

class="com.interwoven.livesite.deployment.impl.BaseDeploymentService"
init-method="startService">

class="com.interwoven.livesite.opendeploy.impl.OpenDeploymentDescriptor">

factory-method="create">

-.*datacapture\.cfg

factory-method="create">

-.*iw/config/(taxonomy|database)/.*$

class="org.springframework.beans.factory.config.ListFactoryBean">

[/PHP]

How would I pass in distinct targetArea's then?

If you can get away with working around the $targetArea^ variable, then that's your easiest bet. You can't specify additional properties like you did because the DeploymentTarget class doesn't have setTargetAppDirectory(String) and setTargetWebDirectory(String) methods. However, both the web deployment task and the URL (headless) deployment task still work with "odSubst_" task variables, so you can put "odSubst_targetWebDir" and ""odSubst_targetAppDir" in your task and you'll get $targetWebDir^ passed to your ODConf. If you wanted/needed to, you can do the same for $targetFarm^ and ignore the PLC's $targetNode^ entirely.

Adam Stoller

They must be preserved in the customer-teamsite-resource-config.xml, and by extension, in your TargetNodes task variable. You can safely add entries in the XML and not use them in your WF, but then what's the point?

Understood.

This is "hard-coded" as a Spring-configurable parameter in OOTB XML configs. [...]

Hmm - this may ultimately be "elegant", but it's definitely heading into the realm of confusion for me right now.

If you can get away with working around the $targetArea^ variable, then that's your easiest bet. You can't specify additional properties like you did because the DeploymentTarget class doesn't have setTargetAppDirectory(String) and setTargetWebDirectory(String) methods.

I had a feeling that would be the case.

However, both the web deployment task and the URL (headless) deployment task still work with "odSubst_" task variables, so you can put "odSubst_targetWebDir" and ""odSubst_targetAppDir" in your task and you'll get $targetWebDir^ passed to your ODConf. If you wanted/needed to, you can do the same for $targetFarm^ and ignore the PLC's $targetNode^ entirely.

This is starting to sound like the easiest way to handle this. True, it moves the "configuration" from a resource / property file on the local disk into embedded JavaScript code within a WFM (to set the task variables the way I want) - but I think it will tend to make the rest of the modification process much simpler (to understand, do, and document - at least for me)

Thanks!

Adam Stoller

Continuing on the theme of the deployment stuff.

If I were to do the odSubst_* parameters - I'm probably losing out on the file list filtering stuff that was going on in the bean configuration - right?

I can probably deal with that by adding my own filtering lists into my custom variants of the deployment configuration file. But it's not just one deployment config file is it? I'd probably have to do all four of the ODHOME/conf/lscs/*.xml and the ODHOME/conf/LiveSite/OpenDeployWebRoot.xml - wouldn't I?

Or - well, I'm still confused. Does OpenDeployWebRoot call the lscs deployments? or do the lscs deployments call OpenDeployWebRoot? Or does the task run multiple deployments - OpenDeployWebRoot and teamsite-areadiff?

The confusion stems, at least in part, because in OpenDeployWebRoot it uses the variable $targetNode, but in the lace/* configs they use the variable $destinationNode - so I'm not sure if I need to replace both of those or just one of them.

I guess I just haven't thoroughly analyzed the black-box process that is Deploy Files and Deploy Production, sigh. If you (or anyone) can clarify the processing steps that go on there (high-level is fine - in terms of which deployment is called where / when / how) - I should be able figure out how to modify things to utilize the odSubst_* variables to do what I want.

Rick Poulin

If I were to do the odSubst_* parameters - I'm probably losing out on the file list filtering stuff that was going on in the bean configuration - right?

I can probably deal with that by adding my own filtering lists into my custom variants of the deployment configuration file. But it's not just one deployment config file is it? I'd probably have to do all four of the ODHOME/conf/lscs/*.xml and the ODHOME/conf/LiveSite/OpenDeployWebRoot.xml - wouldn't I?

Those are two different kinds of filters, and the bean one probably doesn't do what you'd expect. That thing determines whether the target entry is the one that should be used to handle your dev/production deployment. It first attempts to match targetNode (LiveSiteRuntime) with what's recorded in the default.site file(s) for the branch. Then, it makes sure that at least one attached file matches any of the bean filters. It doesn't actually filter the file list in the way ODConf filters do.

Or - well, I'm still confused. Does OpenDeployWebRoot call the lscs deployments? or do the lscs deployments call OpenDeployWebRoot? Or does the task run multiple deployments - OpenDeployWebRoot and teamsite-areadiff?

Task runs multiple deployments, thus not transactional. In 7.3.1 though, when lscs.enabled=true, the LSCS deployment does *both* the LSDS and LSCS portions and OpenDeployWebRoot.xml is no longer used.

The confusion stems, at least in part, because in OpenDeployWebRoot it uses the variable $targetNode, but in the lace/* configs they use the variable $destinationNode - so I'm not sure if I need to replace both of those or just one of them.

targetNode comes from the bean definition; destinationNode comes from lscs-authoring.xml

Adam Stoller

Those are two different kinds of filters, and the bean one probably doesn't do what you'd expect. That thing determines whether the target entry is the one that should be used to handle your dev/production deployment. It first attempts to match targetNode (LiveSiteRuntime) with what's recorded in the default.site file(s) for the branch. Then, it makes sure that at least one attached file matches any of the bean filters. It doesn't actually filter the file list in the way ODConf filters do.

Okay, I suppose that makes sense - though from a logic perspective I'm not quite sure what this means for me (Note: I started composing this response on Friday, and obviously got interrupted in the process - and lost my train of thought - so sorry if this posting seems [more] incoherent [than usual])

Task runs multiple deployments, thus not transactional. In 7.3.1 though, when lscs.enabled=true, the LSCS deployment does *both* the LSDS and LSCS portions and OpenDeployWebRoot.xml is no longer used.

Unfortunately, since we're using 7.2.1, the behavior in 7.3.1 doesn't matter too much just yet - but this is good to know and hopefully I'll remember it if/when.

targetNode comes from the bean definition; destinationNode comes from lscs-authoring.xml

Okay, I'll have to look at this more carefully when I'm back in the office. I think I'm close to getting this working, but it's difficult to keep track of everything ... sigh.

Thanks again for your input / information.

Adam Stoller

I changed the deployment configuration files to use an external farm (defined in odnodes.xml)
I tried to change IWHOME/local/config/lib/content_center/livesite_customer_src/etc/conf/livesite_customer/resources/customer-teamsite-resource-config.xml (say that 5 times fast ;-) so that this:

...
<property name="targetNode" value="LiveSiteRuntime"/>
...

Became this:

...
<property name="targetNode" value="APP_FARM"/>
...

I then rebuilt the toolkit and tried a test deployment through the workflow - which threw an exception:[indent]

[ERROR] DeploymentTask - execute: error during task execution: Production Deployment, message: null
java.lang.NullPointerException at
com.interwoven.livesite.opendeploy.impl.OpenDeploymentServiceAdapter.buildDeploymen ts(OpenDeploymentServiceAdapter.java:239)
at com.interwoven.livesite.opendeploy.impl.OpenDeploymentServiceAdapter.buildDeploymen ts(OpenDeploymentServiceAdapter.java:58)
...
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Proto col.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) at java.lang.Thread.run(Thread.java:619)

[/indent]But if I left it at LiveSiteRuntime (rebuilt the toolkit again) and made sure I defined a replicationFarm with the name "LiveSiteRuntime" (and refreshed OD) it generally appears to work ... in the current simplified environment.

Does that exception sound / look like the kind of thing that folks were saying you needed a patch to 7.2.1 to fix? Or is this something else (perhaps user error)?

Rick Poulin

Right sorry. Another 7.2.1 vs 7.3.1 silly thing.

In 7.3.1, targetName is distinct from targetNode. The PLC matches the default.site's destination node against targetName and matches targetNode with odnodes.xml.

In 7.2.1, targetNode is used for both, meaning that your value must both be recorded in default.site AND in odnodes.xml. If you go back to using APP_FARM in the XML and put that in default.site, your PLC should work.. but obviously that's not what you're aiming to do.

Adam Stoller

Right sorry. Another 7.2.1 vs 7.3.1 silly thing.

In 7.3.1, targetName is distinct from targetNode. The PLC matches the default.site's destination node against targetName and matches targetNode with odnodes.xml.

In 7.2.1, targetNode is used for both, meaning that your value must both be recorded in default.site AND in odnodes.xml. If you go back to using APP_FARM in the XML and put that in default.site, your PLC should work.. but obviously that's not what you're aiming to do.

Ah - this is the first I've looked at default.site (I'm not actually involved with the site development here, just getting all the deployments working).

So I see in there:[html]
LiveSiteRuntime
[/html]So, this is what requires that my farm name be "LiveSiteRuntime" instead of "APP_FARM"?
I suppose I can live with that.
And I might be able to alter the tasks to include a parameter (odSubst_****) for adjusting the target path to include the site name both for "production" and "development".

I really wish there was [decent] documentation that identified all the various configuration files, their purpose, and then the purpose of each element within. It's so easy to get lost bouncing around between this config file and that property file and that XML file.

nipper

I really wish there was [decent] documentation that identified all the various configuration files, their purpose, and then the purpose of each element within. It's so easy to get lost bouncing around between this config file and that property file and that XML file.

Yea, well I wish I had a million dollars. And that wish is about as likely as yours to come true.

Adam Stoller

Yea, well I wish I had a million dollars. And that wish is about as likely as yours to come true.

Actually, I think you have a better chance for your wish :-)