Requesting Specific Hosts, System Pools, or Bare Metal

Host Requirements

The test template try to make it easy to specify host requirements, by exposing them to the user in multiple ways. If you're familiar with linchpin topologies, you could go ahead and edit the topology file to specify your requests in the "hostrequires" block the same way you would do so using beaker xml. However, for simplicity, this is also configurable by passing in a hostrequires specification directly into the ProvisioningConfig's hostrequires variable. As of CI Libraries release v1.2.1, this can also be overridden at the TargetHost level through the bkrHostRequires variable.

Examples

These examples demonstrate how to modify provisioning configuration. This assumes that you've gotten the config object using the directions shown in the CI Libraries Documentation.

Requesting a Specific Host

You can request a specific host by setting the following:

config.hostrequires = [[ tag: "hostname", op: "=", value: "name-of-host" ]]

Requesting a System Pool

You can request a specific host by setting the following:

config.hostrequires = [[ tag: "pool", op: "=", value: "name-of-pool" ]]

Requesting a Bare Metal Server

You can request a specific host by setting the following:

config.hostrequires = [[ tag: "hypervisor", op: "=", value: "" ]]

Combining Specifications

You can even combine specifications by separating the inner structures with commas. For example, this would provision a bare metal host in pool "name-of-pool".

config.hostrequires = [[ tag: "pool", op: "=", value: "name-of-pool" ], [ tag: "hypervisor", op: "=", value: "" ]]

Advanced Specifications / Wildcards

Beaker uses SQL queries to filter database records against the criteria that you supply in 'hostrequires'. This means that we can taken advantage of this knowledge of how these work to perform more advanced requests. As specified in the Beaker XML Docs, the four operations supported in the op tag are !=, like, == and =. The last two are the same, and they test if the value of the attribute specified by tag is an exact character by character match. The opposite of that behavior is available through !=, which tests to see that valueof the attribute specified bytag` is explicitly not a character by character match.

The like operation is more complicated. It performs an SQL LIKE operation of the template provided in value against the attribute specified by tag. Like supports wild card characters:

• % Match any number of characters
• _ Match a single character

As an example, if you were trying to match any host with a hostname that begins with qe-, you could specify the following in the value parameter.

"qe-%"

If you wanted to match hosts with names matching the following pattern 'qe-box-#', where # represents any single digit, you could match that using the following in the value parameter.

"qe-box-_"