With the upcoming split in our production masters, and possible future clustering/podding, it would be great if we could manage what master a slave should connect to without having to log on, edit buildbot.tac, gracefully shutdown, and restarting buildbot. Some ideas: * Use opsi/puppet to update buildbot.tac, and reboot the slave after every N runs so that the new settings get applied. * Create a web service that outputs the correct settings (maybe even the entire buildbot.tac file? that would solve some other issues as well...) for a given slave. The slave could run this as the last step in all its builds, and then know how to restart itself when the file is updated.

We'll have to be aware of the auto-respawn of buildbot that occurs on Mac and Linux (via /Library/LaunchAgents/ and Puppet respectively). Moving buildbot.tac aside before shutting down buildbot would probably prevent a restart while modifying buildbot.tac. Not so sure how we'd deal with two things starting it up in quick succession, perhaps buildbot does that already.

(In reply to comment #1) > We'll have to be aware of the auto-respawn of buildbot that occurs on Mac and > Linux (via /Library/LaunchAgents/ and Puppet respectively). Moving buildbot.tac > aside before shutting down buildbot would probably prevent a restart while > modifying buildbot.tac. Not so sure how we'd deal with two things starting it > up in quick succession, perhaps buildbot does that already. This can actually be a good thing, we don't have to worry about how to start buildbot again on Mac and Linux, since we're already doing that! We could modify buildbot.tac in-place, and then shutdown the slave. It would get started back up a few minutes later.

Sound like an exploratory future project.

Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

The main impetus for this bug was to be able to move slaves around between different masters easily. That is going to addressed by work in bug 508673. Other issues are usually specific enough that they would likely require manual intervention.