First, the Deadline installers for both the client and repository have an option “–optionfile”. However, I can’t find any information about how this file is supposed to work, what values are valid in it, etc.
Second, does the Deadline client installer hard-code any information about the host the client is being installed on when it runs? In other words, if we install the client to a template directory and then mirror those directories to many machines, is Deadline going to freak out because of a duplicate installation “fingerprint” of some kind?
Third, would it be possible to eventually add an installer option for an actual installation prefix for everything? Right now, the “–prefix” option essentially means “put the main client files here, but I’m still going to create some other (required) folders in hard-coded locations.”
Finally, can you provide a list of all of the directories the client installer creates and populates outside of the main “prefix”? Since we will be mirroring the installation, I want to make sure we don’t miss any of these hard-coded directories.
How would you expect this to work? Would you want control over the individual locations listed in (4) below, or do you want everything under the same prefix?
These are the folders created by the installer:
/opt/Thinkbox/Deadline6 (default installation location)
/var/log/Thinkbox/Deadline (where the logs are stored)
/var/lib/Thinkbox/Deadline6 (where things like deadline.ini and other system settings for Deadline are stored)
~/Thinkbox/Deadline6 (where per-user settings for Deadline are stored)
Finally, there is also the DEADLINE_PATH environment variable that the installer creates. It points to the Deadline bin folder (ie: /opt/Thinkbox/Deadline6/bin).
Ideally a bit of both, but the latter would be more immediately useful.
If you look at the way most autoconf-generated configuration scripts work on Linux, they typically give you an option for a base prefix, and everything is installed under that as if that were the filesystem root. This kind of thing is very useful when setting uph automated delployments, since it allows you to immediately see what a given package is trying to install, as well as keeping everything nice and contained, and making propagation of new versions pretty painless.
Thus, in the case of the Deadline client, consider the default behavior to be equivalent to passing / as the prefix. If I were to pass a prefix of /foo/bar instead, I would expect to see these resulting directories:
/foo/bar/opt/Thinkbox/Deadline6
/foo/bar/var/log/Thinkbox/Deadline
/foo/bar/var/lib/Thinkbox/Deadline6
/foo/bar/etc/profile.d/deadlineclient.sh <-- Just found out about this one
(Note that things like user preferences are a special case, and would be excluded from this change).
Additionally, it would be nice if Deadline options to change where the various applications write log files, or which config file to use when launched, so that the applications weren’t bound by any installation parameters. For the config file, it would look for one in a predefined location by default, but a parameter could be added to allow it to be overridden (for testing/debugging, etc). The same could be done for the log path: By default, it would look for a path in whatever config file is being used, but this could be overridden by a parameter:
Honestly, the parameterization and config file override ideas are more a product of me spitballing on the installation prefix (as well as being spoiled by how flexible *nix programs tend to be), so those are really more of a suggestion for continuing to make Deadline more flexible.
I see that the installer is always writing a script to /etc/profile.d, which I didn’t know before. This is an example of the kind of thing that we want to be aware of when the client is installed, in case we need to modify or otherwise control it, and why having a true installation prefix is so important. Are there other examples of one-off files like this that I should be on the lookout for? And what is the DEADLINE_PATH environment variable used for?
Thanks for the information. It’s funny, because when we first started supporting Linux way back in version 3, we had everything under one folder, and we got back a ton of negative feedback.
So probably the best way to go is to allow these three paths to be customizable, and using a config file in the installation folder would then be used by Deadline to find these folders. If users want them all in the same folder, they can configure it to do so. And like you said, you could pass a config file override from the command line if you want to use different paths. We can definitely add this to the wish list.
I have one question though regarding the deadlineclient.sh script. We put it in /etc/profile.d so that it runs automatically. If it were installed to /foo/bar/etc/profile.d for example, how would that work? Just wondering if this is another one of those special cases that should be left as is or not.
Sorry, I forgot that we used a shell script to set that variable on Linux. The only other file would be the deadline6launcherservice script that gets installed to /etc/init.d if you choose to install the Launcher as a daemon.
The environment variable is actually just used by our integrated submission scripts so that they know where deadlinecommand is. So it might not even be needed for your slave machines.
That’s a good question, because theoretically, even if you installed the whole thing under a custom prefix, some part of Deadline is still going to expect that environment variable to be set in all cases. My counter-argument to that would be that if someone is using the installer in that way (unattended or CLI installation), they should know what they’re doing, and that there’s little point in including an option that only partially does what it says it does. If I build a program on Linux with a custom installation directory, it’s still my job to make sure it’s on the PATH if I want to use it without a full path.
The reason we would want to see everything under the same root directory is so we would know up front what all needs to be distributed and be able to decide whether we want to set DEADLINE_PATH in another way, whether we want to handle starting the launcher daemon on our own, etc. Plus, the “installation” we do is going to be to a template directory anyway, rather than onto an actual slave, so if those scripts end up getting installed locally on whatever machine executes the installer, we’re just going to have to go back and clean them up later anyway.
