NuWa Slave : automated build/test setup

Running a slave provides :

• automatically updated and tested dybinst'allation
• web interface to the status of the installation including history of build/test status

How to setup a slave

Pre-requisites : python 2.5?, setuptools, bitten ( 0.6dev-r561 )

Although bitten is installed by dybinst into nuwa python as part of the nosebit external, it is more logical to install this into your system python as the slave can then perform green-field dybinst builds without recourse to existing dybinst-allations.

svn checkout http://svn.edgewall.org/repos/bitten/branches/experimental/trac-0.11@561 bitn
cd bitn
python setup.py develop       ## probably with sudo

• more recent revisions of bitten have incompatibilites with the trac 0.11 master

Interactive Test Running of the slave

• Verify that bitten-slave is installed and in your PATH and is the expected standard version

  [blyth@belle7 ~]$ which bitten-slave
  /usr/bin/bitten-slave
  [blyth@belle7 ~]$ bitten-slave --version
  bitten-slave 0.6dev-r561
  

• export dybinst into directory to be used for slave builds (you could use an existing dybinst-allation also)
• interactive test run of the slave

  ./dybinst trunk slave 
  

  • this should fail complaining of lack of config in your $HOME/.dybinstrc

• add or create $HOME/.dybinstrc containing connection credentials

  slv_buildsurl=http://dayabay.ihep.ac.cn/tracs/dybsvn/builds
  slv_username=slave
  slv_password=***
  slv_loghost=http://your.address       ## if you are able to publish logfiles 
  

If your credentials are correct the expected startup messages are :

[blyth@cms01 trunk]$ ./dybinst trunk slave
Updating existing installation directory installation/trunk/dybinst.
Updating existing installation directory installation/trunk/dybtest.


Mon Aug  9 16:12:04 CST 2010
Start Logging to /data/env/local/dyb/trunk/dybinst-20100809-161204.log (or dybinst-recent.log)


Starting dybinst commands: slave

Stage: "slave"... 


dybinst-slave invoking : /data/env/local/dyb/trunk/installation/trunk/dybinst/scripts/slave.sh trunk

Contacting the master instance, this will take a while.  Go get muffins...

=== slv-main : derive config /home/blyth/.bitten-slave/dybslv.cfg from source /home/blyth/.dybinstrc
[INFO    ] Setting socket.defaulttimeout : 15.0 
[INFO    ] Setting socket.defaulttimeout : 15.0 
[DEBUG   ] Sending POST request to 'http://dayabay.ihep.ac.cn/tracs/dybsvn/builds'
[INFO    ] No pending builds

Note that slave asked the master if there are any builds to do and got reply No pending builds , the default config is to ask the master every 5 mins if there is anything to do.

In order for the master to instruct the slave to perform builds you must send the hostname to Simon :

[blyth@belle7 ~]$ hostname
belle7.nuu.edu.tw

who will inform add the slave to the master through the Trac Admin web interface.

Running the slave continuously

Supervisord is recommended to keep the slave running,

• http://supervisord.org/

Install supervisord into your system python with easy_install or pip :

easy_install supervisor

For tips on using supervisord, see :

• http://dayabay.phys.ntu.edu.tw/tracs/env/browser/trunk/base/sv.bash
  • ( includes functions to setup redhat init.d scripts that restart supervisord and all its children when your machine is rebooted )

An example of the supervisord config used to keep the dybslv running :

[program:dybslv]
environment=HOME=/home/blyth,BITTEN_SLAVE=/usr/bin/bitten-slave,SLAVE_OPTS=--verbose
directory=/data1/env/local/dyb
command=/data1/env/local/dyb/dybinst -l dybinst-slave.log trunk slave
redirect_stderr=true
redirect_stdout=true
autostart=true
autorestart=true
priority=999
user=blyth

Refreshing the slave build

For reasons of efficiency the slave build (which can be performed multiple times each day) is done as an update build. Certain types of commits are known to be likely to cause issues with update builds, including :

• changes to DataModel classes

In order to freshen up the build you can try rebuilding after removing various directories, in progressively increasing levels of cleanliness :

• rm -rf NuWa-trunk/dybgaudi/DybRelease/$CMTCONFIG
• rm -rf NuWa-trunk/dybgaudi/InstallArea
• rm -rf NuWa-trunk/dybgaudi/* ; svn up NuWa-trunk/dybgaudi

To trigger a slave build after the removal, invalidate the last build on the node in question using the web interface (BUILD_ADMIN privilege required)

Monitoring the slave node

After many failures on a slave, it is wise to check running processes ps aux, it can happen that many tens of stuck nuwa.py processes can kill your node. Clean up with pgrep -f nuwa.py ; pkill -f nuwa.py