| <!-- HTML snippet loaded in the dashboard view --> |
| <center>Select a view from the menu above.</center> |
| <h1>Definitions</h1> |
| <dl> |
| <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 |
| intervention.</dd> |
| |
| <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> |
| </dl> |
| <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: |
| <ul> |
| <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> |
| </ul> |
| </p> |
| |
| <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> |
