[Buildbot-devel] Masters behind firewalls?

[Fred L. Drake, Jr.]

On Tuesday 07 September 2004 03:11 pm, Brian Warner wrote:
 > Not really. The build slaves have to be able to make a TCP connection to
 > the master. I designed it that way because I figured it was more likely
 > that a publically-visible project would have a publically-visible master,
 > and because it allows the build slaves to be behind NAT boxes.

That makes sense.

 > That said, if your firewall arragement is such that you can allow the
 > slaves to connect to the master, then you can do it. The slaves make a TCP
 > connection to the host and port you configure into them at mktap time. Any

Ok, then I'll talk to our sysadmin crew this week to figure out what they're 
willing to do.  Maybe I'll ply them with Thai food...

Part of the goal is to avoid the expense of setting up a dedicated host for 
the master in the zope.org cluster.  Since this isn't an absolutely critical 
service, there's no real need to host it otherwise.

 > The hard part about this approach is setting up those tunnels
 > automatically. I think there is an ssh/slogin option to not run a command
 > at the other end (or close stdin/stdout or something) which might be
 > appropriate.

There is, but making these things really work automatically all the time is 
enough nuissance that I don't want to depend on something that fragile.

 > Of course, the slaves will have to be able to check out the sources too,
 > which may be difficult unless the source repository is outside both

That's not an issue for us since slaves of the only publicly reachable master 
only need to get to the public zope.org repository.

 > firewalls. I'm considering adding a source-acquiring BuildStep which would
 > perform a source checkout *on the master* and then send a tarball with the
 > results down to each slave: chews up a lot of bandwidth (on a system that
 > may not have have a lot), but could be useful in certain configurations
 > like that one, particularly for small trees.

Could be good to have eventually, though I don't think I'll need it for my 
current plans.  Such a step could be an advantage as well, since the 
generated tarball could be compressed and cached effectively if there are 
many slaves that are likely to use the same one before further changes are 
made to the codebase.

 > That technique could also help if the sources are not quite available
 > publically and there is some secret or SSH key you need to get a copy. In
 > particular, for the meta-buildbot I'm trying to set up, I'm thwarted by
 > sf.net's 5-hour latency between the time you check something in and the
 > time it appears on the public (read-only) anonymous-CVS repository. I must
 > either use a tree-stable-timer of like 6 hours, or use something gnarly in

A 6-hour timer can be unworkable for an active project.  ;-)

CVS, for all it's warts, allows some pretty powerful things to happen in the 
commit and log hooks.  A loginfo hook could synchronize the affected portions 
of the tree with a remote copy.  I'd actually like to see someone implement 
this as a re-usable component for working with SF myself.  I don't have time 
to do so myself at this point.

 > So anyway, your mission (should you choose to accept it) is to find a way
 > to let those slaves make those TCP connections to the master.

Sounds like coercing the network admins is the simplest approach.  And a good 
excuse for Thai food as well!  (Like I need an excuse.)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>