yellow team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Sat, May 19, 2012 at 9:14 AM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
> On 05/16/2012 03:59 PM, Robert Collins wrote:
>> This is great news.
>>
>> So roughly 10m + 19m + 265m/workers. Neato.
>>
>> Testr will ignore the layers if you configure the new option we added;
>> it will still show a layer that fails to startup. This may help with
>> the idle time aspect.
>>
>> What do you think of us getting say 16cores, hyperthreaded, *one*
>> machine. That would make the action from idle snappier, at the cost of
>> either contention when there are serial landings, or complexity in
>> buildbot to say 'only run one test at a time, devel || db-devel'.
>
> The serial approach is trivial.  I've gotten it working and tested it,
> and it's fine.  It turns out that BuildSlaves have a "max_builds"
> keyword argument available at instantiation.  It defaults to None
> (infinite) and we can easily set it to 1.  It would be less than five
> minutes of work in the data center.  We'd probably want to expose this
> in the juju charm as well, for our own tests, but that would be very
> easy.  I've hacked on it just a bit already.

Thats great news and certainly preferrable to spending a bunch of time
dealing with concurrency; it lets us potentially buy more CPUs for the
single machine case (because we can do 2.4GB/core rather than than
4.8GB - but obviously wouldn't let us double the cores, as that would
end up with the original memory amount ;)).

So yes, +1 on not digging into concurrent builds. We *may* find there
are things there that still matter (such as being able to have a hot
test DB to reduce the per-thread time), but again, thats out of scope,
we're getting a great result as it is.

-Rob