When running lots of schedulers / builders on relatively
few machines it becomes increasingly important to manage
resources, i.e. strict the number of builders that can
run simultaneously. A first step into that direction
may be the use of semaphores to indicate how many
builders may run in parallel on a given machine.
However, when managing multiple projects with multiple
buildbot setups the above isn't enough either. Scheduling
builds needs to take into account the 'outside' world,
such as the current load of a machine. If there is only
a single machine to which a builder is assigned, it may
mean that a build has to be delayed.
However, if there are multiple equivalent machines
available, a single builder could be assigned to a
class of equivalent machines, instead of a single
machine, and the scheduler can then assign a build
to the machine with the lowest load.
As a different use case taking advantage of the same
feature, consider a project with a big number of
builders, and a big community of contributors who
are willing to share hardware for testing - remotely.
On connection, the build master would assign short-lived
builders to them, aggregating results as they arrive.
Here again, the main new feature is a loosened relationship
between builder and build slave.
![[Buildbot Logo]](/trac/chrome/site/header-text-transparent.png)
