Auto configuration doesn’t seem to be working. I’ve got a rule that is set to match using a host regex of .* and setting a number of configuration options, but in every slave log, I just see this on startup (with verbose logging enabled):
2014-07-07 11:17:13: Scanning for auto configuration
2014-07-07 11:17:16: Auto Configuration: No auto configuration could be detected, using local configuration
2014-07-07 11:17:16: Connecting to repository
2014-07-07 11:17:16: Info Thread - Created.
Slaves are running Linux (I haven’t tested any OSX machines yet).
I don’t quite follow… I want to match all hostnames, and .* should cover every possible hostname. In your example, is “hostname” a token of some sort? Or are you saying I should substitute in an actual host name there (which would defeat the purpose of the regex)?
Having .* as a host name regex should definitely work; I just tested it here to confirm, and it picked up my settings just fine. Did you try restarting Pulse after configuring the rule set, to see if that made a difference?
If you try making a ruleset for a specific machine as a test (either by IP or hostname), does that ruleset get picked up?
Yes, I tried restarting Pulse, but it made no difference.
Nope. Same problem (I restarted Pulse again after creating the new ruleset). Just to confirm, those host regexes are matched against the hostname, not the slave name, correct?
Yes, it is the hostname. Is it possible that there’s a firewall blocking the autoconfig port that Pulse is trying to use? Pulse should be listing the port it’s listening on in its log when it starts up (might need to have verbose Pulse logging turned on).
This is all on our internal network, and there’s no firewall. I have confirmed that UDP 17061 on the Pulse machine is open and listening via nmap from another machine:
rDNS record for 100.100.100.25
PORT STATE SERVICE
17061/udp open|filtered unknown
Hmmm, another thing that could be messing with this would be if your Slaves have an override for the auto-config port in their deadline.ini, but Pulse doesn’t.
Can you check your deadline.ini file on your Slaves and check for an ‘AutoConfigurationPort’ entry? It theoretically shouldn’t have one, since 17061 is the default port.
Should be located here on Linux:
/var/lib/Thinkbox/Deadline6/deadline.ini
So, because these aren’t targeted UDP packets, it’s probably pretty likely that there is a router of some kind between the Slaves and Pulse, and that it’s filtering out those broadcasts.
If verbose logging is enabled for Pulse (or not according to a brief skim we did over at Jon’s desk), if any Slave auto-config UDP packet comes in on that port, it should say something (it may filter out garbage, don’t remember). If nothing’s being printed, the problem is before the rulesets are applied.
Just for funzies, try using a wake on lan testing app and wireshark/tcpdump to see if any of those broadcasts make it through.
Can you think of any machines that might be segregating the network? Getting Pulse as close to the Slaves as possible should help this whole thing.
OK, I think we tracked this down. Basically, it comes down to the fact that we use subnets to segregate our network internally, and the 255.255.255.255 broadcast won’t cross subnets.
Out of curiosity, has there been any thought put into redesigning the auto-configuration mechanism in a future release? The current system seems highly reliant on a rather simplistic network layout. Since the location of the Mongo server can be known immediately, it doesn’t seem like it would be too big of a deal to pull connection information for a Pulse server, rather than trying to probe the entire network.
Auto-configuration has already been re-worked for Deadline 7 so that only the repo path is pulled from Pulse. Once the slave has successfully connected to a repository, it will pull all the other auto-config settings directly from the database.
Ah, cool. I like the idea of it pulling the configuration from Mongo. However, if the initial broadcast method is still the same, I think it will still fail to work across subnets.
This would only affect pulling the repo path. We’re not sure of a better way of dealing with this though, because if a slave doesn’t already have a repo path set up in its deadline.ini file, it can’t go directly to the database because it wouldn’t know where that is either.
So you’re saying that in the new system, auto-configuration will work for everything except the repo path even if the slave can’t hit a Pulse server with its UDP search packet (i.e. by just using the repo path stored in its config file)?