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 configuration files

farabi

We are currently setup on OD4.5 on Solaris. We have about 300 branches and 300 corresponding OD config files. For e.g,

Branch /main/internet/www/ has a corresponding OD config file /opt/opendeploy/config/internet/www/iw.odclient.cfg.

We are in the process of upgrading to OD5.6.
1. Is it recommended to have 300 individual OD config files or have one OD config file with 300 deployment configuration details?
2. Would it mean more time for the OD server to traverse through the single OD config file (single xml having more than 300 config information) when compared to having 300 individual files having individual deployment detail?
3. Waht are the advantages/disadvantages of having the database-managed config files vs XML managed deployment configuration files?

Thanks

Find more posts tagged with

Comments

Bubas_IWOV

Hi,

I would ask first, how do you kick those deployments? Using the GUI? I have to be honest I haven’t use OD4.5 in 3 years.
Now just some more questions so that I can try to help you:

Do these 300 deployments deploy to the same target servers?
Do these deployments always deploy to the root path?

B

farabi

how do you kick those deployments? Using the GUI?
No, we use the CLT. there is no GUI for OD4.5

Do these 300 deployments deploy to the same target servers?
In most of the cases they deploy to the same target servers. A few deployments deploy to other target servers.

Do these deployments always deploy to the root path?
In most of the cases they deploy to the root path in the target servers. A few deployments deploy to non root path.

Thanks

Adam Stoller

Thing of the deployment configuration files as scripts and the consider the objective in a logical manner to try and discern patterns of use.

Chances are you can figure out a way to parameterize the configurations so that you can reduce the number of deployment configurations from 300 to something closer to 3.

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

Bubas_IWOV

Hi,

I would even say that one script would be enough.
In your case i would use a cfg files, from which a smal perl script would read the required values and then deploy to the target servers, as normally you always deploy to the root of the servers and to the same target servers, that doesnt seem too complicated. What you think fish? :-)

Regards
B

Adam Stoller

I'd say fit the design to the environment requirements and not the other way around. Whether they end up with one configuration or ten, or 300 depends on the requirements of the environment.

I think reducing from 300 to 3 is very likely, from 300 to 1 is possible but might not make sense (it sounded like there were was a basic design to the confiurations with several different versions here and there)

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

AttachPDF_PageOUT.562.dcpackage.zip

output.pdf

Bubas_IWOV

Good point.

B