Concurrent Upgrading (Jun 02, 2016)

Version: Deadline 8.0

BACKGROUND

With Deadline 8.0 having recently celebrated its one-month anniversary as a public release, many of our more eager clients have already made the switch to the latest and greatest version. However, as with any other software, some people prefer to take the more cautious ‘wait-and-see’ approach to upgrading. This is obviously a perfectly valid approach to take with new versions of any software, especially when the proper operation of said software is mission-critical to your pipeline, and definitely one that we fully support here at Thinkbox.

As such, we fully understand the importance of testing and validating new software within your actual pipeline first, instead of blindly deploying it across your entire farm (while crossing your fingers and praying to a wide variety of deities). In a perfect world, everyone would have an extra farm kicking around, which is somehow completely identical to their production farm and is somehow currently unutilized on which to do this kind of validation testing.

The good news for our fellow cautious upgraders is that Deadline 8.0 is very easy to test alongside older versions. This allows for evaluation, testing, and validation of all the new features in Deadline 8.0 in the context of your production farm, without actually impacting your production deadlines. Once done, the actual rollout can then follow stress-free at your own pace (hopefully with less praying required).

PREPARING YOUR INFRASTRUCTURE

With the introduction out of the way, let us jump right in and start by looking at the changes you’ll need to make to your server machines in order to start testing a new version of Deadline. The simplest of these is the License Server. Once you’ve gotten your new license file from our Sales team, it should simply be a matter of replacing your existing one and restarting your license server – more information on this process can be found here. And don’t worry, our licenses are backwards-compatible, so all of your current software will continue to work, even with the newer license file! Even if you don’t want to go through this step quite yet, the Deadline 8.0 Workers still support License-Free mode when there are only two Workers or less on the current Repository, which should be more than enough to get started!

Next up is to set up the Deadline Repository and Database server. These can co-exist on the same machine as your Deadline 7.0 equivalents, however the repository must be installed to a new location, and a new Database should be created. This remains true when performing the actual switch as well as side-by-side testing – Deadline does not support in-place upgrading of the Repository or Database across major version boundaries (e.g. from Deadline 7 to Deadline 8). I would also like to take this opportunity to remind any readers that the minimum recommended database version for Deadline 8 is MongoDB 3.0 (as opposed to 2.6 for Deadline 7), so if you maintain your Database on a separate server make sure to upgrade! Note that if you’re letting the Repository installer create the database for you, this step will be taken care of for you by the installer. For a refresher on how exactly the installation process goes, don’t forget to re-visit our documentation on the matter!

WHAT ABOUT THE CLIENT MACHINES?

Now that you’ve got the server machines taken care of, it’s time to install the Deadline 8.0 client on a couple machines, and start trying out your new Deadline 8.0 infrastructure! Again, if you’re in need of a quick refresher on the process, we’ve got you covered. The Deadline 8.0 client will happily live side-by-side with an older client, without interfering with each other too much (with one caveat that I will cover later on), so you just can go ahead and install it on your machine. All of Deadline’s binaries, settings, and temporary files, are kept in separate folders that are named according to the current major Deadline version, which should help enormously in keeping your new-version tests in their own little sandbox.

The one place where Deadline 7 and 8 settings bleed over a bit comes into play with our integrated submitters, which can be installed for many third-party applications (e.g. 3dsMax, Maya, Nuke, etc.). These scripts will use whichever version of Deadline was last installed to perform submissions. This is determined by a special path which is stored in a slightly different spot on each OS. On Windows and Linux, it is simply in an environment variable named ‘DEADLINE_PATH’, and on Mac OS X it is stored in a file located at /Users/Shared/Thinkbox/DEADLINE_PATH. The environment variable on Linux is set at boot by a script located at /etc/profile.d/deadlineclient.sh. In order to switch your submitters back to using 7.0, it should be a simple matter of changing this path to point to your old installation.

An alternative way to update this value (without having to futz with scripts or environment variables) is to run any of our Submitter Installers for your current OS. These will automatically change the DEADLINE_PATH variable to whichever Client directory you specify during the installation.

Having installed the client on your machine, you should now be able to start deploying this to some render nodes, which will bring you one step closer to testing your full pipeline on the new version. This will be very similar to deploying the client on your own machine, minus the concern with DEADLINE_PATH, since presumably no one will be remoting in to submit Deadline jobs from Maya on a render node. Even if that flow is part of your pipeline for some reason, it should by no means be a road block, just something to be aware of!

Another difference to keep in mind with Workers in particular, however, is that while they can co-exist and run different versions at the same time on the same machine, the individual Worker applications will not be aware of each other. This is a potential pitfall if, for example, both Workers try to start rendering heavy jobs that compete for the same system resources (RAM, CPU, I/O), it could at the very least lead to inefficient use of your hardware. So, in light of that, we recommend either disabling one version’s Worker (and switching as needed) on a machine that is hosting both, or ensuring (through use of Pools and Groups) that the two Workers are running different types of jobs that won’t starve each other of system resources.

BUT WHERE HAVE MY SETTINGS GONE?

Obviously, requiring a fresh Repository and Database also means having a blank slate in terms of settings. And now that I’ve mentioned this, I’m sure you must be dreading recreating all those carefully crafted settings from your 7.0 farm in your newly minted 8.0 setup. This should be nothing to fear, however, since Deadline now has a tool to do most of this work for you. Since Deadline 7, the Monitor has an Import Repository Settings dialog, located under the Tools menu, which assists in copying settings from one repository to another.

While not all settings will port over cleanly from older versions (largely due to incompatible changes in how we store the data), importing from 7 to 8 should grab almost everything. Monitor Layouts are not compatible at time of writing, unfortunately, but aside from those it should just be a matter of selecting what you want to bring over and clicking the ‘Import Settings’ button!

THIS IS ONLY THE BEGINNING!

And that should pretty much cover the basics – you should now have a fully workable setup, from submission to rendering, on which you can detect and make any necessary adjustments to your setup before doing a full roll-out. The whole process may sound overly-simplistic, but that’s only because there actually isn’t that much to it. There’s a whole slew of new features and improvements to discover in Deadline 8, but they won’t discover themselves – so just get your hands on the new installers and get testing already!