[OpenAFS-devel] Re: slave suggestions for buildslaves?

[Jason Edgecombe]

On 06/21/2013 10:25 AM, Andrew Deason wrote:
> On Thu, 20 Jun 2013 20:28:12 -0400
> Jason Edgecombe <jason@rampaginggeek.com> wrote:
>
>> It's easy to add multiple slaves to a builder, and the slaves will be
>> used in parallel, but I think that slaves are use in the same order as
>> the config file and not as a round-robin.
> Well, the order of which one is used first I didn't think really
> mattered. But if we have 2 submitted changes, one change will go to one
> slave, and the other change will go to the other slave, right? You're
> not talking about one change being submitted to both slaves in parallel,
> correct? (since that wouldn't be very useful)
Correct, each change is given to the next slave that is free. A commit 
is only worked on by a single slave (per builder). If we have commits A, 
B, C and slaves, X,Y,Z, then Then the commit->slave mapping will be 
{A,X},{B,Y},{C,Z}, assuming that the each commit arrives before the 
others have finished.

My point was that, with a non-saturated queue, slave X will be the 
busiest and Z will be the least busy. The slaves will share work, but 
not equally. This could be changed if we upgraded the software on the 
buildmaster, but I'm blocked on upgrading.

To have multiple cores/machines contribute to a single compile, then you 
must use "make -jX" or distcc.
>> My biggest concern about having multiple slaves in a builder is that
>> the slaves might have slightly different configurations which yield
>> inconsistent results. If that's fine with the other dev's, then you
>> can ignore this. If it's a concern, maybe we could use puppet or
>> something similar to keep things in sync.
> In my opinion, that's okay for the 1.6 branch. That is, it's an
> acceptable downside for getting faster builds. This effectively just
> means that if a build fails, it's harder to see which specific commit
> broke stuff, but it's still very likely that buildbot will notice if
> there is a problem (before, say, a release).
>
> For master, speed is less of a concern and knowing specifically which
> commit broke the build is more of a concern, so maybe this could just be
> for the stable branch builders.
>
For platforms with multiple slaves, we could have two builders, one with 
all the slaves, and one with only one slave. The single-slave builder 
could be assigned to the master branch and the multi-slave builder could 
be assigned to the other branches.

I think that multi-slave problem might be simplified if we were able to 
use the ability of newer buildbots to choose which slave to use.

BTW, having multiple builders per slave can make for interesting 
scheduling of the slaves.

We also have the option of running multiple slave instances on the same 
host if the host has multiple procs and the host has spare resources 
while compiling. Of course, this assumes that the compilations and tests 
won't conflict if multiple test runs are happening simultaneously.

Jason