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

Multiple Deployment elements in a single conf file

suj

Hi all,

I am in a process of migrating OD 4.5 files to OD 5.5.1. In 4.5 we used to have one config file which we used to invoke specifying which deployment to be invoked.

In 5.5.1 also we are planning to make it a single config file with multiple definitions and replication farmsets and deployment will be done using parameter substitution.

The problem here is that, we have a deployment with DNR and others without DNR. Since it is not allowed to have more than one Deployment element (as per the DTD), is there a way to achieve the same without splitting the deployments to two files? In short, is there a facility to invoke deployments using names as in 4.5?

TIA

rgds

suj

Find more posts tagged with

Comments

Migrateduser

First of all, you should update to OD56 which is the latest and greatest release. As to the question, since DNR is associated with deployment only, and you are right that there must only one deployment for config file. In that sense, you have to split to more than one config file. In OD56, we allow multiple definition for every deployment. You may be leverage this feature for some other similar situations.

suj

Thanks for your reply...

I was goiing through the OD5.6 manuals..but i still don't find a feature that solves my problem..OD 5.6 still maintains one deployment element per configuration file..In this case how can i put a DNR deployment as well as a non-DNR deployment in the same config file? since i have not used OD 5.6 i am unable to understand how it can help me in this regard..it would be great if you can throw some more light on this..

rgds

suj

Migrateduser

Within a deployment config, you can specify multiple <definition> elements.

Within the same deployment config, specify a single <deployment> element, which may contain multiple <execDeploymentTask> elements, each of which refers to a particular definition to run and may contain DNRs.

So you could have something like:

<deployment ... >
<execDeploymentTask useDefinition="Definition1" />
<execDeploymentTask useDefinition="Definition2" >
<deployNRun>
...
</deployNRun >
</execDeploymentTask >
</deployment>

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

suj

Hi

Thanks for your input. My requirement is slightly different. I do not want the DNR deployment & other deployment to be run at a time. Basically i would like to have the facility to club deployments in one single file, execute them as different instances by invoking by a deployment name (as in OD 4.5.x). Any thoughts on why interwoven took this facility off when it brought out the latter version

Thanks

suj

StoryTeller.pdf

FULL_ACCESS_NO.XML.ZIP

Migrateduser

I'm not clear on exactly what you're trying to do, but you can use the parameter substitution feature to pass into the deployment job which definition to execute.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

suj

Let me make it clear..

I have 2 kinds of deployments. One with DNR & other without DNR. They are to be triggerred separately. If i write something like this,

<deployment ... >
<execDeploymentTask useDefinition="Definition1" />
<execDeploymentTask useDefinition="Definition2" >
<deployNRun>
...
</deployNRun >
</execDeploymentTask >
</deployment>

Then both definition1 and definition2 gets executed at once which should not happen.

Ideally i would like to have something like this..

<deployment name=WithoutDNR>
<execDeploymentTask useDefinition="Definition1" />
</deployment>

<deployment name=WithDNR>
<execDeploymentTask useDefinition="Definition2" >
<deployNRun>
...
</deployNRun >
</execDeploymentTask >
</deployment>

and I would invoke the deployment config file by specifying the name of deployment.

Eg. iwodstart test WithDNR

In this way, i can use a single config file for all kind of deployments.

rgds

Cell.jpg

Repeater.jpg

Substitution.jpg

Migrateduser

OK, I see. Param substitution would allow you to pass in the definition you want to run into a single execDeploymentTask. But the need to have the DNR run in one case and not the other interferes with this.

If you really don't want to have two separate config files, perhaps an (admittedly ugly) way to work around this is to also pass in the DNR script command as a parameter. In the case of "no DNR", you would essentially pass in a no-op script to run.

Anyone else have any suggestions or ideas?

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

suj

Thanks for the input..As you said that may not be the ideal way to do it but can always be there as a last resort..But i guess interwoven can consider this as a feature request..especially when this was the way OD used to work in 4.5.x...

rgds

Adam Stoller

It's basically a trade-off between some old functionality and new functionality (not to mention a completely different architecture to the program being used).

However, I'd like to understand the scenario a bit more...

Can you explain the process by which you would be invoking these different deployments - and why you couldn't just as easily have that process call a distinct deployment configuration file rather than passing in one or more paramters to a single deployment?

I.e., somewhere you're making the determination of which deployment to call (WithoutDNR, WithDNR) - why not just call iwodstart with different config files (WithoutDNR.xml, WithDNR.xml)?

The only case I can think of where what you're asking for really makes sense - is if both <execDeploymentTask>'s would be executing the exact same deployment definition - just one situation requires it to have a DNR run and the other doesn't. Though from your descriptions where you have "definition1" and "definition2" that doesn't seem to be the case.

If it were the case though, I think a variant of what Todd suggested makes sense - use parameter substituion - but I'd try doing it a bit more simply (IMO):

<execDeploymenTask useDefinition="DEF0">
    <deployNRun>
        ...
            <script cmd=".../script.ipl $flag^"/>
        ...
    </deployNRun>
</execDeploymentTask>

In this case, you just pass a flag to the script to tell it whether it should run or not, and have the script do a quick exit if it isn't supposed to run. This also allows for more flexibility in the script to do more different things when it does run...

Oh well, that's my $0.02 for now.
(Almost done catching up with this forum, one more forum to go...)

--fish
(Interwoven Senior Technical Consultant)

suj

Thanks for the input..

Let me make my situation clear..

We have n number of sites currently running & more to come up..We are automating the deployment process for these sites. If we use separate configuration files for each situation there will be atleast 10 config fies per site..moreover the situation or definitions for these deployments are similar..the difference being in the replication-farms,destination etc. The idea is some thing like this..

We will have a pre-configured OD config file with defintions in place to recieve parameters. The only static member in the deployment file will be the replication farms..which will be added/edited as new sites add-up or existing ones are edited.

In tis OD config file we will have just 4 definitions. The definitions will be fully built at run time by parameter substitution and which is the definition to be executed for each instance is also passed as a parameter to the deployment element.

The parameters for the config file are stored in property files which are edited/added using a web interface and a few parameters are passed from the environment.

We will have the following advantages with this kind of set-up.

1) Less number of files (infact just one).
2) Ease of understanding the process. (Any meintenance guy can easily figure out the situation).

iwodstart will be invoked with relevant parameters specifying the instance.

Your valuable suggestions are most welcome...

rgds

Adam Stoller

My general suggestion is don't try to force a square peg in a round hole ;-)

I don't mean to be condescending here - it's just that if the differences between the deployments in any two situations are significant - then don't try to treat them as the same thing.

Consider having one confiuration file for deployments without DNRs and one for deployments with DNRs - your concept of doing the substitutions and reducing the number of files still holds true, it's just not "quite" as reduced as it was before.

Alternatively, consider generating the deployment configuration files on the fly - based on the information you're storing in these properties files - thus not only can you control the source, target, nodes, etc. - but you can control whether or not to generate an execDeploymentTask with or without a DNR.

I've done this in the past - and it proved to be very successful - but it took over a month to really get the design nailed down, implement, and test...

--fish
(Interwoven Senior Technical Consultant)

suj

I had given a thought to your idea of generating files on the fly. But i guess this might become a problem if the user who starts the deployment does not have write access to the conf directory. Is there a way we can place the config files in some other directory?

rgds

Adam Stoller

Currently, no - I'm not sure if it's planned or not (the issue has been raised a few times), but this was part of the design so I'm not sure how quickly it is likely to changed.

Perhaps the wrapper script can be run via some setuid or setgiod process such that it would have the ability to perform the desired write into the IWODHOME/conf directory?

--fish
(Interwoven Senior Technical Consultant)

suj

Thanks..In that case i guess i should proceed with the 2 config file design..

it may not be a bad idea if interwoven can consider to put multiple deployment elements in a single config file in forthcoming versions along with changing the default config file location.....just in case some one tries to be adventurous like this.. Smiley Wink

rgds