How to set up a BuildBot Slave for OpenAFS

Rationale

Why would I want to? OpenAFS supports multiple platforms, but the strength of support for each of those individual platforms is directly proportional to the amount of testing done thereon. Although there are many different types of testing that can be done, one of the most basic is that of changes to the code base. A BuildBot slave allows for automated testing of each gerrit commit and is therefore a great resource to developers, most of whom do not have the time or resources to test their code on every platform prior to submission. Therefore, we encourage you to contribute a system as a build slave for a platform not already covered! You know you want to!

Approach

This is a consumer-oriented, high-level "how-to" to (hopefully) show how simple it is to set up your own build slave (and thereby contribute to OpenAFS!). This document is not intended to be platform-specific -- there are just too many different ways of doing things across Linux/Windows/SunOS/IRIX/AIX/BSD etc. There are additional notes elsewhere on this Wiki (see: BuildbotMasterNotes) about setting up the BuildBot Master, and some of this material is covered there as well -- however, this page is an attempt to make the process more understandable (specifically the buildslave setup).

Overview

A quick overview of the process:

  1. Acquire suitable system
  2. Install required software
  3. Compile OpenAFS from git
  4. Create buildbot account and home directory
  5. Contact OpenAFS BuildBot admin for configuration details
  6. Edit configuration files
  7. Start build slave
  8. Set up startup scripts
  9. Optional configuration

Of note: since BuildBot slaves pull all their information from the master (rather than having it pushed to them by the master), there is no need to open an incoming port on your firewall, etc. As long as the slave can contact the master on the port you're given (which will be explained later), you're good to go!

Hardware Requirements

  • Any system which OpenAFS currently supports (the greater diversity of build slaves, the better)
  • Enough free disk space to build OpenAFS tree (a couple gigabytes should do)

The machine does not necessarily need to be dedicated entirely to being a buildslave; a build slave could run on any lightly-loaded, non-critical system (subject to your security requirements, etc., of course). Some of the OpenAFS buildslaves are run by volunteers at their own homes, for instance.

If you happen to have an older system with multiple processors, you can run more than one build slave instance on the same machine. The workload will be distributed across them by the master: successive gerrit commit builds are started on the next free instance, thus reducing the overall time to test multiple commits.

Software Requirements

BuildBot has the following software dependencies:

Links to the above software websites are provided for reference only -- you may very well have a more convenient method for installing software on your platform than downloading the source, building, and installing by hand. Check public software repositories for your platform first to save yourself some effort. BuildBot is not particularly sensitive to dependency versioning, so you may not need the absolute latest version of everything installed. (For instance, BuildBot 0.7.12 is known to work with Python 2.5.2, Git 1.7.9, ZopeInterface 3.3.0, Twisted 9.0.0.)

Git version 1.7.9 or above is required. The "git clean -e" option must be present and the "git clean -X -e excluded-file" behavior must be correct.

And, of course, you'll need to install BuildBot itself: http://buildbot.net/trac

Compile OpenAFS from git

Use git to clone the openafs repo, then make sure the software will compile successfully. For Unix platforms, the typical build process is "sh regen.sh && ./configure && make && make dest" The actual buildbot builds will configure using the --enable-checking argument to configure (as well as several others); this activates more compiler errors and you will probably want to do manual builds with checking enabled, to fix any build errors encountered before the buildslave enters regular use.

Create buildbot account and home directory

It is recommended that you use a special-purpose non-priviledged user account to run the build slave (i.e., "buildbot"). The build master does not need to know the account's password -- in fact, the account does not necessarily need remote login priviledges and may be locked or otherwise secured as long as your platform still allows you to run commands as that user.

Test that you can run the buildbot command successfully (without error messages that might indicate installation issues): /path/to/buildbot

Contact OpenAFS BuildBot Master admin for configuration details

Contact jason at rampaginggeek.com regarding the settings you'll need to add your machine as an OpenAFS build slave. These settings will include:

  • buildmaster_host: this is the OpenAFS build master
  • port: this is the port on the build master which your slave will talk to
  • slavename: a unique descriptive name for your new build slave, usually representing your operating system and architecture (and not necessarily anything to do with your systems' hostname)
  • passwd: a password assigned to your slave for use in connecting with the master

Create your build slave configuration

As your buildbot user:

Inside the user's home directory (say, /home/buildbot), create a subdirectory which will contain all of the buildslave files (say, /home/buildbot/slave1). Buildbot will not touch anything outside of this directory.

Substituting the appropriate values from above, the execute:

/path/to/buildbot create-slave /home/buildbot/slave1 buildmaster_host:port slavename passwd

Starting with buildbot version 0.8, the command-line tool was split into buildbot and buildslave, so the buildslave utility should be used with such newer buildbot versions.

Check the configuration file /home/buildbot/slave1/buildbot.tac to make sure the settings you entered are reflected in it. Make sure that "usepty" is set to "0". "usepty = 1" it is known to fail on at least one architecture.

Optional, but recommended: Edit the /home/buildbot/slave1/info/{admin,host} files to describe the system (in host) and send yourself a shout-out (tell who you are in admin). These show up on the web if you drill down to the build slave information on the OpenAFS buildbot web portal, so you may want to obfuscate your contact information.

Note: if you are planning on running multiple OpenAFS buildslave instances, you simply repeat this and all later steps, specifying a different base directory (i.e., /home/buildbot/slave2, /home/buildbot/slave3, etc.)

Start build slave

/path/to/buildbot start

Check the logs to make sure it started properly. Check the OpenAFS BuildBot web portal to see the build progress presented graphically.

There may be some kinks to work out of the system with the first few builds, especially if you are contributing a slave system for a less-heavily-used platform whose support might suffer from bit rot between releases (hey, it happens!).

Set up startup scripts

Self-explanatory. Make sure they run /path/to/buildbot start as your buildbot user.

Set up log rotation and various other useful settings

The buildbot.tac configuration file can be used to optimize your build slave. For instance, you may want to change maxRotatedFiles so you don't end up with a bunch of logs littered about /home/buildbot/slave1/. Have a look at the BuildBot documentation if you wish, though you can expect to be able to take a fairly hands-off approach to administering your new OpenAFS build slave.

Link to current BuildBot documentation: http://buildbot.net/buildbot/docs/current/

Thanks for your help!