Slave property ipnr not reported

[mbuisman@…]

consider the script step: <sh:exec executable="echo" args="Slave: ${name} ${family} ${ipnr} ${os} ${version} ${machine} ${processor}"/>

and the bitten-slave output when called without config: <slave version="2" name="localhost"><platform processor="x86_64">x86_64</platform><os version="2.6.18-164.11.1.el5" family="posix">Linux</os></slave>

Then I expect the corresponding Log for this step to be something like:

Slave: localhost posix 192.168.1.2 Linux 2.6.18-164.11.1.el5 x86_64 x86_64

instead I get:

Slave: localhost posix ${ipnr} Linux 2.6.18-164.11.1.el5 x86_64 x86_64

Among other things this means I can't use ipnr to identify the target platform.

[hodgestar]

Recipes variables are found from two sources. Most are read from the slave's configuration file with defaults obtained from Python's platform module. The ipnr isn't one of these. The other source is the variables added to the recipe XML by the master before it sends the recipe to the slave. The ipnr isn't one of these either although the slave IP address is available here and could be added with something like:

xml.attr['ipnr'] = build.slave_info.get(Build.IP_ADDRESS, '')

to line 237 of bitten/master.py. Perhaps it should be added for consistency.

I'm a bit confused by "I can't use ipnr to identify the target platform". Surely you would use ${platform} to identify the platform? If you want to identify particular slaves it's better to do so by ${name} I guess.

[osimons]

ipnr is available for platform rules at server/config side. The slave does not try to detect it's own IP for passing along to the server as that may be unreliable (several ip's, proxying and so on). Instead the IP is detected by the server by reading REMOTE_ADDR from the request.

See #266 and #421 as illustrations of why ipnr is not an really a good attribute to keep around. Bitten has switched to tokens (corresponding to Trac sessions) for identifying slaves uniquely for the duration of the build. Instead of adding, I'm tempted to instead remove all visible references and documentation for ipnr.

No doubt use-cases for ipnr can be constructed, but I don't really see anything that can't be solved by other attributes. Giving your slave a name and using that for rules and interpolation is really a much more flexible solution.

[anonymous]

Replying to hodgestar:

I'm a bit confused by "I can't use ipnr to identify the target platform".

Our development, test and production environments are rather exact copies of each other. One major difference is the IP address (of which they only have one). So I can't use any of the other identifiers, unless I use a .INI file. I prefer to keep the number of files (that require documentation, etc) to a minimum. It would have been nice to have the bitten-slave report some unique property that does not come from a file.

[olaf.meeuwissen@…]

I had been using the ipnr without any trouble until I moved the master behind an Apache proxy running on the same host. All of a sudden the master was seeing the proxy's IP address (localhost) rather than the slave's.

Considering the general negative comments on using ipnr, I won't check whether Apache can be configured to pass the slave's address. I'll just cook up something else like a checksum of the partial output of ifconfig on the slave ;-)