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

Concurrent deployments to a receiver

debus

Can an OpenDeploy v6.0.2 receiver receive deployments from 2 different base nodes concurrently ? The target directories and deployment profile names are different.

If the answer to the questiom above is yes, can the source base nodes be different version (one is v6.0.2 and the other is v6.1.0).

If not is the best solution to install 2 receiver instances on the target server ?

Thanks

Find more posts tagged with

Comments

gzevin

Can an OpenDeploy v6.0.2 receiver receive deployments from 2 different base nodes concurrently ? The target directories and deployment profile names are different.

If the answer to the questiom above is yes, can the source base nodes be different version (one is v6.0.2 and the other is v6.1.0).

If not is the best solution to install 2 receiver instances on the target server ?

Thanks

Pete,

the concurrency is supported. At least, I believe the receiver will wait (queue up) the second deployment if it happens at the same time. Even in 5.6 I have OD that is able to recieve stuff from a number of boxes, and I have configured a number of topologies that were accepting from different senders.

As to the version differences, this should not be an issue - As long as the compatibility matrix is achieved. Given the fact you are going to deploy from a newer version, this could pose a problem (I'd think that IWOV would not certify that).

jkm

Can an OpenDeploy v6.0.2 receiver receive deployments from 2 different base nodes concurrently ? The target directories and deployment profile names are different.

If the answer to the questiom above is yes, can the source base nodes be different version (one is v6.0.2 and the other is v6.1.0).

If not is the best solution to install 2 receiver instances on the target server ?

Thanks

Yes Pete, this is possible and we can queue up the deployments on the rcvr side. But for your information we have seen some problems in terms of deployment time while running concurrent deployments in transactional mode.
In your case target directories are different then it should not be a problem.

debus

My understanding was that it could be done, but I simulated a test from a base node to base node (ie: same server) and the second deployment failed like it was timing out. The target directories are different. More specifically it worked fine for filelist deployments but failed for area comparison dateDifferent deployoments.

It's good to hear others have done same and it works OK as my simulation is not entirely accurate as all source and target nodes are the same server.

Thanks.

gzevin

My understanding was that it could be done, but I simulated a test from a base node to base node (ie: same server) and the second deployment failed like it was timing out. The target directories are different. More specifically it worked fine for filelist deployments but failed for area comparison dateDifferent deployoments.

It's good to hear others have done same and it works OK as my simulation is not entirely accurate as all source and target nodes are the same server.

Thanks.

the concern I would have had is that the newer version is usually is not good as a sender.

Adam Stoller

the concern I would have had is that the newer version is usually is not good as a sender.

Unless something changed somewhere - the strategy for updating OD has always been to update the sender first, and then the receivers - so your statement here would seem to be in direct conflict with that.

Sometimes you need to configure something on the sender to tell it you're doing a down-rev deployment, but I think that was primarilly in 5.6/6.0 days - if you're down-rev receiver is at least 6.0 (possibly 5.6) then I believe the up-rev sender should be able to determine the down-rev version on the fly via the ACK/NACK communications - and "do-the-right-thing"

If this isn't happening, then I'm pretty sure it classifies as a bug and should be reported to Support.

jkm

My understanding was that it could be done, but I simulated a test from a base node to base node (ie: same server) and the second deployment failed like it was timing out. The target directories are different. More specifically it worked fine for filelist deployments but failed for area comparison dateDifferent deployoments.

It's good to hear others have done same and it works OK as my simulation is not entirely accurate as all source and target nodes are the same server.

Thanks.

What is the Time Out interval in your config files Pete ... may be while deploying the complete areas it is taking too much time and it may time out?

gzevin

Unless something changed somewhere - the strategy for updating OD has always been to update the sender first, and then the receivers - so your statement here would seem to be in direct conflict with that.

Sometimes you need to configure something on the sender to tell it you're doing a down-rev deployment, but I think that was primarilly in 5.6/6.0 days - if you're down-rev receiver is at least 6.0 (possibly 5.6) then I believe the up-rev sender should be able to determine the down-rev version on the fly via the ACK/NACK communications - and "do-the-right-thing"

If this isn't happening, then I'm pretty sure it classifies as a bug and should be reported to Support.

well, I saw so many strategies, belive me, the compatibility matrix is such that down-revving on the sender part was no so readily supported, compared to the down-revving of the reciever.

as I said to Pete, I'd check the compatibility matrix, as all we are just speculating about this particular issue