Using Priority Pools

Priority Pools allow you to group resources into pools that can be prioritized differently among groups. Each pool’s resources can potentially be used by any build, but builds originating from a pool’s “owner” always have first priority to use that pool’s resources. Using Priority Pools allows you to manage resource allocation for builds more efficiently.

Follow this procedure:

Enable Priority Pools through either the Cluster Manager or cmtool.
- Using the Cluster Manager, go to Administration > Server Settings and select Priority Pools.
- Using cmtool, run this command:
  cmtool modifyServer --resourceManagerType prioritypool
  ▼
Define your pool using the Agents > Resources page. A pool resource uses this form: pool_xxx, for example, ` pool_a`.

When you define a pool on the Resources page, you must include “pool_”. When you include a pool in the --emake-resource option, you can omit pool_ from the option.
Go to Agent > Agent Policies and set agent allocation policy to shared.

Launch eMake with the following option:

--emake-resource="<pool resource>:<static resource>"▼

Information about values for --emake-resource= :

When adding a pool resource to the option, you can omit pool_ ` from `pool_xxx: and use xxx: only.
A pool name (before the `: ` ) is not required. Not defining the pool name means the build will not use a pool resource.
A resource name (after the : ) is not required. Omitting resource name causes the build to attempt to use any unused resources that it is allowed to use.

When attempting to use a pool resource as a normal resource, there is a period (default is 60 seconds) during which, before your build starts, a build from the pool resource’s owner can take back the resource.

Use case 1: high performance builds

You have two pools of resources, one for high performance builds and one for low performance builds. You want to ensure that high performance builds can always use the more powerful 8-core machines and that low performance builds use the 4-core machines. You also want to allow high performance builds to use the 4-core machines when low performance builds are not running. And you want to allow low performance builds to use the 8-core machines when high performance builds are not running. You also have two special software packages, so you define a static resource for each.

Pool makeup:

Pool a—High performance build resources, five 8-core machines, defined on the Resources page as __pool_a

The machines are named h_1, h_2, h_3, s_1, and s_2.

Pool b—Low performance build resources, five 4-core machines, defined on the Resources page as __pool_b

The machines are named h_4, m_1, m_2, s_3, and s_4.

Two static resources are also defined on the Resources page:
s —This resource includes these machines (which have a specific software package): s_1, s_2, s_3, and s_4 (from using host mask s* )
m —This resource includes these machines (which have a specific software package): m_1 and m_2 (from using host mask m_1, m_2 )

Launching eMake with --emake-resource=

means that the build uses

"a:"

Pool “a” and any unused resources

"a:s"

Static resource “s” (four machines). If a low performance build is running, only machines “s_1” and “s_2” (two machines) are used.

"b:m"

Static resource “m” only

"a:m"

Static resource “m” only. If a low performance build is running, no machines are available and the build must wait.

":s" or "s"

Static resource “s” if low and high performance builds are not running. If a low performance build is running, then only machines “s_1” and “s_2” are used. If a high performance build is running, then only machines “s_3” and “s_4” are used. If low and high performance builds are running, no machines are available and the build must wait.

":" or ""

Any unused resources (this is considered a common build)

Use case 2: multiple departments

There are two departments and each department has its own pool of machines. They want to contribute their machines toward a common pool so each department can use the other department’s machines while still ensuring that their own machines are available for their department’s builds. One department owns 20 machines and the other department owns 10 machines. Each department also owns a small number of 64-bit machines. IT contributes an additional four machines that any department can use.

Pool makeup:

Pool Depta—Department A’s resources, 20 machines, defined on the Resources page as __pool_Depta

The machines are named a_01 through a_16 and a_17_64 through a_20_64 (these last four machines are 64-bit).

Pool Deptb—Department B’s resources, 10 machines, defined on the Resources page as __pool_Deptb

The machines are named b_01 through b_08 and b_09_64 and b_10_64 (these last two hosts are 64-bit).

Static resource 64bit —This resource includes these machines: a_17_64 through a_20_64 and b_09_64 and b_10_64 (from using host mask *_64) .
General build machines—IT department-supplied general build machines, four machines

Launching eMake with --emake-resource=

means that the build uses

"Deptb:"

Pool “Deptb” and any unused resources, using general build machines first and then Deptartment A’s machines if that department is not running a build.

"Depta:"

Pool “Depta” and any unused resources, using general build machines first and then Deptartment B’s machines if that department is not running a build.

"Depta:64bit"

Static resource “64bit” (six machines). If Department B is running a build, only “a_17_64” through “a_20_64” (four machines) are used.

":" or ""

Any unused resource, using general build machines first and then Deptartment A’s and Deptartment B’s machines if those departments are not running builds (this is considered a common build).