On Sat, May 19, 2012 at 9:14 AM, Gary Poster <[email protected]> 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 -- Mailing list: https://launchpad.net/~yellow Post to : [email protected] Unsubscribe : https://launchpad.net/~yellow More help : https://help.launchpad.net/ListHelp
