Is there a real need to update the Deadline Launcher with every build of Deadline?
It seems like updating the launcher is a massive point of failure for Deadline. We’re constantly manually hand holding slaves to help them start/stop the services etc every single update. Is there an argument against breaking version continuity between the launcher and the workers? Create a bullet proof launcher that handles upgrading the sub-components but keep the manager itself relatively stable and reliable.
Short term – I think the Deadline Launcher does enough that, yes, we do need to be able to update it via auto-upgrade. That aside, even if we did not need to have the door open to changing the Launcher-specific binaries, it uses the same DLLs as everything else (Deadline.dll + FranticX.dll). This means that while it’s running it’s holding a read lock on those files (on Windows anyways), so at the very least it needs to be shutdown while those files are replaced.
I think long-term, there’s definitely merit for making the Launcher a bit thinner, or splitting it in half, or something of the sort. I think we should still have provisions to have the Launcher upgrade itself, but if it is completely independent from the rest of Deadline it could at least be a separate flow.
Correct. I’m not arguing it can’t update itself just that it’s on an independent track that maybe only needs to be updated on major point releases (if even) when there is a feature or bug that actually affects the launcher. It would make it far less likely to be taken down by another process and far less likely to fail during updating if it’s not having to bootstrap itself and briefly take that leap of faith and shut down with the hope of restarting. When the launcher needs to do some work with Deadline.dll maybe it just spawns up a worker application to complete the task and report its completion.
Get it to the point where it always is listening even if Deadline itself is dysfunctional.