blob: 83e195cf968dc6fc97e0e9fa9f5861c2d2c6e766 [file] [log] [blame]
<!-- HTML snippet loaded in the dashboard view -->
<center>Select a view from the menu above.</center>
<dt>Silo</dt> <dd>A set of interchangeable slaves. For example, a Darwin9
slave isn't interchangeable with a Linux64 slave. Silos are based on
relatively fixed attributes of the slaves' hardware and sofware
configuration -- attributes that cannot be changed without manual
<dt>Pool</dt> <dd>a set of masters and slaves, where any of the slaves can
be allocated to any of the masters. Pools are the primary configuration
knob for the allocator.</dd>
<dt>Trustlevel<dt> <dd>The trust level specifies the kind of code that can
run on this slave. It currently maps to the various levels of
version-control commit priviledges -- tryuser and core.</dd>
<h1>Allocation Process</h1>
<p>Within each pool, the allocator attempts to balance the slaves in each silo across the available masters. The balancing algorithm proceeds as follows:
<li> determine the pool for the slave</li>
<li> determine the silo for the slave </li>
<li> for each active master in the pool, count the number of attached slaves from the silo </li>
<li> attach the new slave to the master with the lowest count, sorting by master name where counts are equal </li>
<p>Note that the balancing applies to the intersection of a silo and a pool.
The more slaves in each such intersection, the better the allocator can
perform. As such, we should make all efforts to minimize the number of
distinct pools and silos into which we divide our slaves.</p>