EC2 buildbot: make it possible to have a single slave image

Bug #418549 reported by Gary Poster
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Won't Fix
High
Unassigned

Bug Description

This is actually an upstream feature request in the code we added to buildbot, but we are the ones who contributed the pertinent code, and who care.

Right now, every time we need a new slave image, we actually need to make three new images: devel, db-devel, and bzr. Other builds would mean other slave images, such as bug 383348.

This is time consuming and wasteful. This is particularly annoying because the difference between these images is simply a name and password in the buildbot.tac file.

Fixing this could be done by making the master able to initiate conversations with the slave, rather than the other way around. I am told that the underlying Twisted protocol is symmetric, so this should not be too difficult.

Alternatively, I believe there are AWS/EC2 tools for providing data to an image as it instantiates. The master could provide the necessary information, and the image could have the necessary smarts to put it in the right place.

Changed in launchpad-foundations:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I think it would be reasonably possible to use "user supplied instance data" http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?AESDG-chapter-instancedata.html to allow the slaves to know which user to connect as.

Changed in launchpad-foundations:
status: Triaged → In Progress
assignee: nobody → Michael Hudson (mwhudson)
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

This turns out to depend on using a newer buildbot...

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Oh and if we can get this working in a way that lets us use the same image for ec2test that would be awesome.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Didn't get to this in my stint as Build Engineer.

Changed in launchpad-foundations:
status: In Progress → Triaged
assignee: Michael Hudson (mwhudson) → nobody
Revision history for this message
Henrik Ingo (hingo) wrote :

FYI: I'm working to solve this issue. I'm going for a more generic solution actually, to run arbitrary shell script provided via the user-data meta-data. But that should also solve this. (My own use case is also a buildbot farm and the motivation is the same as here.)

Revision history for this message
Henrik Ingo (hingo) wrote :

Hi all

I finally got around to polishing and publishing my solution for this.
http://openlife.cc/blogs/2011/may/easy-way-manage-virtualcloud-images-outside-userdata-and-runurl-scripts

I've used this in my own work and boy, it makes the heavy lifting of maintaining different images just go away! So many hours saved in just a small project.

I suppose the new buildbot slave class still lacks a manual page, but other than that I welcome anyone to take a look.

Also, I don't have a direct connection to the buildbot project, so if anyone wants to push this upstream, I'm happy to receive help there.

Changed in launchpad:
status: Triaged → Fix Committed
Revision history for this message
William Grant (wgrant) wrote :

Our buildbot no longer uses EC2.

Changed in launchpad:
status: Fix Committed → Won't Fix
Revision history for this message
Henrik Ingo (hingo) wrote :

Ok, no harm done, since I was only solving my own problems here.

Just making a note for people who come here reading this, that the same solution is generally applicable for any other public or private cloud too, whenever you use virtual images. (rackspace/openstack, vmware, kvm, xen...) The only piece missing then is that you'd have to create your own subclass of AbstractLatentBuildSlave in buildbot, as the EC2LatentBuildSlave is specificall for EC2.

Afte thar, the concept of using runurl and an external configuration script works the same with all virtualization technologies (and I strongly recommend it).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.