Well, we actually use the same exact distribution all over the network, so every computer has same exact file structure, since it’s being shared. Only local files per computer are temps, swaps and caches.
Hmm, with that type of setup, I’m not sure what the best way to support multiple slaves instances would be. It might not even be possible, because we need to store the configuration on the local machine in a persistent way (so the temp folder won’t work). Do you guys ever plan on using the multiple slave feature with this setup? Maybe we just need a way to disable it…
Yes, disabling this feature could fix the problem here. Or maybe deadline could somehow detect a machine that it’s currently running on and based on that it could filter out the slaves. But for now we dont think we will take advantage of multi-slave feature, since the licensing is per slave, and currently we have a limited number of them based on number of computers in our studio.
Hm, is it possible to start the launcher without slaves and then launching the slave by “deadlineslave -nogui” (which doesnt have that problem) and still use the Remote Control feature? Because that’s the main profit we’re missing here.
Cheers!
Wojtek
That’s what we’ll do then.
Under the hood, the launcher is passing the -name argument to the slave, which tells it which slave it should be. Without the -name argument, the slave will just use the machine’s name as the slave name, which is why “deadlineslave -nogui” works for you right now. We are going to add support for a setting called “MultipleSlavesEnabled” in the shared deadline.ini file (the one in the Deadline install folder, not the per user folder). By setting this to False, the slaves will simply ignore the -name argument, and multiple slaves will be squashed. The nice thing about your setup is that you’ll only have to set it on once spot. 
We will add this new option in the beta 3 release, which we hope to get out sometime this week.
Cheers,
- Ryan
Great, thanks!
What about tieing it to MAC address? Could you implement an option that stores a slave XML somewhere on the repository:
de80::32e6:faf5:8160:f6c%13 Render05_NUKE, Render05_MAXThen when it starts up it would just edit the local slave info.
We want to keep the multiple slave configurations separate from the repository, because when a slave initially launches, it’s not aware of which repository it will connect to. So it becomes a “chicken before the egg” scenario. It’s the same reason we don’t store stuff like licensing, autoconfiguration port, launch slave at startup, etc, on the repository.
Cheers,
- Ryan
A little minor visual error yet to fix. After setting “…MultipleSlaves…” to False both in the installation directory and in the local user home it shows starting of the multiple slaves but actually starts correctly only one:
[deadline@render01 ~]$ deadlinelauncher -nogui &
[1] 26191
[deadline@render01 ~]$ Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Deadline Launcher 5.1 [v5.1.0.45606 R]
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Grafika01
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Grafika14
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Grafika17
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render01
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render02
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render03
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render04
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render05
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render06
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render07
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render08
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render09
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render10
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render11
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render12
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render14
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launching Slave: Render15
Launcher Thread - Launcher thread initializing...
Perfoming remote admin check
Remote Administration is now enabled
Launcher Thread - Remote administration is enabled
** (/opt/package/deadline_5.1b4/bin/deadlinelauncher.exe:26191): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Launcher Thread - Launcher thread listening on port 5042
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
** (/opt/package/deadline_5.1b4/bin/deadlineslave.exe:26243): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Deadline Slave 5.1 [v5.1.0.45606 R]
** (/opt/package/deadline_5.1b4/bin/deadlineslave.exe:26243): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Auto Configuration: No auto configuration could be detected, using local configuration
slave initialization beginning.
Info Thread - Created.
Trying to connect using license server '@grid.humanark.com'
The license file being used will expire in 23 days.
** (/opt/package/deadline_5.1b4/bin/deadlineslave.exe:26243): WARNING **: System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Checking repository integrityAh, yes, that’s to be expected with your current setup. All the slave configurations are still visible to all the machines because they share the same local storage, so they can potentially all try to start up. However, because the feature is disabled, the rest just shut down immediately and only the original continues to run.
Cheers,
- Ryan