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

Deployment hosts list

System

Is there a way to get a list (in perl) of the receivers to be acted upon in a deployment.

Find more posts tagged with

Comments

Migrateduser

Can you be a little more specific? Do you mean in a single deployment? A transactional deployment to many servers? A fan-out deployment? There are many different flavors of deployments. What is your requirement?

Adam Stoller

Is there a way to get a list (in perl) of the receivers to be acted upon in a deployment.

Are you talking about within the deployment process or as an external (perhaps pre- or post-operative) process?

One could certainly write a Perl script to process a deployment configuration file and determine the replicationFarm being used and either read the nodes from there, if defined "internally" - or read the nodes from the odnodes.xml file, if defined "externally".

Providing a mode detailed description of what you are truly trying to accomplish will tend to result in more specific answers or approaches to solutions.

Migrateduser

I am running a transactional deployment and I have some custom scripts for handling nodes that may have missed a deployment or 10 and it would be real helpful if I could get a like of hosts (receivers) that are configured for the deployment. I was hoping that there was something already existing that would give that list.

Thanks

P.S. I did ready the docs and did not find them very helpful, We looked for training and did not find any availiable cost effective training. And we did hire a consultant and I am trying to complete and implement what was done.

Adam Stoller

I am running a transactional deployment and I have some custom scripts for handling nodes that may have missed a deployment or 10 and it would be real helpful if I could get a like of hosts (receivers) that are configured for the deployment. I was hoping that there was something already existing that would give that list.

If you're doing a transactional deployment, then either all nodes configured for that deployment should be updated, or none of them should - it's not like some hosts would have been updated and others not.

You don't mention whether the deployments are file-list based, teamsite-difference based, or directory-difference based. If it's the last one, and you've had to add, or remove and later add-back, a node to the replication farm, then you should have no issues with getting that node updated. If it's one of the other two methods of deployment, you should just periodically run the last one to make sure that all nodes are kept in sync.

Trying to do more than that is probably more work than it's worth.

Migrateduser

Sorry I forgot to put in that we have the quarum set to allow 2 or 3 failures that will allow successful deployment. This is to allow that when systems are down or out for some reason. the deployments still occur. This is where we have custom code to get these systems up to date when they are availiable again. And a reverse deploy is not an option due to the time it takes to do the scans and checks each time.

We are doing a dir difference against the last edition and using only opendeploy and controlhub.

Adam Stoller

Sorry I forgot to put in that we have the quarum set to allow 2 or 3 failures that will allow successful deployment. This is to allow that when systems are down or out for some reason. the deployments still occur. This is where we have custom code to get these systems up to date when they are availiable again. And a reverse deploy is not an option due to the time it takes to do the scans and checks each time.

We are doing a dir difference against the last edition and using only opendeploy and controlhub.

If you're doing a directory comparison between a specified edition and the target filesystem - you shouldn't have to worry about which nodes didn't get updated the first time - those that did will be a no-op deployment, those that didn't will get updated.

If, however, you're trying to track which nodes continue to fail over time - then you need to either put in place a DNR script for tracking failures or parse the deployment log files. You'd have to look through the in-memory log of data via a DNR script to see if there is sufficient information there to track which target node failed (I'm not sure if that information is present) - so you might have to parse the log files regardless.

Experiment and see what you find out.

Migrateduser

We copy new files into the work area, submit to the stage and then do a diff from the last edition to the current stage. Then the deployment is from that. If a host fails and we have the quarun set such that the deployment passes. We track that and record the failure for the next deployment. On the next deployment we try to "Catchup' the out of sync host(s). I need to be able to check the replication farm list to ensure the hosts in our list are still part of the deployment. Or if new ones are added We need to know.

Thanks for the help.

Adam Stoller

We copy new files into the work area, submit to the stage and then do a diff from the last edition to the current stage. Then the deployment is from that. If a host fails and we have the quarun set such that the deployment passes. We track that and record the failure for the next deployment. On the next deployment we try to "Catchup' the out of sync host(s). I need to be able to check the replication farm list to ensure the hosts in our list are still part of the deployment. Or if new ones are added We need to know.

Thanks for the help.

I cannot say that I fully understand your implementation, but I've pointed out ways to extract the names of the nodes in the replication farm, and ways to determine which nodes failed to receive a deployment. At this point, I think you need to figure out your process and try putting both pieces into action.

I'm not sure that anyone here can help you too much more than that without actually writing the code for you... and that's not what where here to do (for free)

Migrateduser

I cannot say that I fully understand your implementation, but I've pointed out ways to extract the names of the nodes in the replication farm, and ways to determine which nodes failed to receive a deployment. At this point, I think you need to figure out your process and try putting both pieces into action.

I'm not sure that anyone here can help you too much more than that without actually writing the code for you... and that's not what where here to do (for free)

Thanks for the help I think I have gotton what I need by parsing the deoloyment XML file.