We’re going back and forth a little on whether to make use of the client auto-upgrade feature, and I’ve got a couple of questions related to client upgrades.
After a client is auto-upgraded, is the launcher restarted as well as the slave?
If so, is it restarted in the same state it was running in previously (daemon vs. GUI)?
Is it “safe” to run the client installer while a launcher and slave are running on a given machine without stopping them? In other words, if we went with our existing deployment system, would we be able to replace the client installation completely while the slave and launcher were running without interrupting any potentially running tasks, and then trigger delayed slave/launcher stop-start sequences manually later?
No! Well, it’s untested and therefore unsupported…
The nice thing about auto-upgrading is that after upgrading the repository, you can use remote control in the slave list right-click menu to restart the slaves after they finish their current task. This way, rendering is uninterrupted.
Speaking of autoupgrading, Pulse really really needs to shutdown and restart when it detects the farm has changed. We always forget about pulse and it doesn’t regularly restart since it’s not rendering jobs or idle. So we lose power management every time we upgrade for a couple days before we remember to restart it.
Well, that’s a good question. Do you want an out-of-date PULSE trying to submit jobs to an updated repository? I feel like a failed submission is better than a submission from an out-of-date client (pulse in this instance).
We’ve been nervous about implementing an automatic shutdown and startup system in case there are issues during the upgrade. We’ve actually updated our docs recently to recommend upgrading Pulse first (we even gave it its own section so it stood out more): thinkboxsoftware.com/deadlin … r_Upgrades
Now we know that not everyone reads the docs, but hopefully it will at least help avoid the number of times this comes up.