Beaker driver :: Documentation for Artemis provisioning service

Credentials

When Beaker access is protected by authentication, driver can be configured to include credentials when talking to its backend.

Specification

username: <string>
password: <string>

Example

username: a-beaker-username
password: corresponding-password

Beaker groups

To avoid provisioning machines owned by particular Beaker groups, driver can be configured to avoid them.

Specification

avoid-groups:
  - group-1
  - group-2
  ...

Example

avoid-groups:
  # While our Beaker account has access to these groups, don't provision machines owned by them.
  - special-gpus
  - laptops

Each provisioning Beaker job would then contain two sets of elements to implement this behavior:

<group op="!=" value="$groupname"/> to instruct Beaker to avoid this group,
<hostname op="!=" value="$hostname"/> to instruct Beaker to avoid machines owned by these groups.

The list of machines owned by each group is cached, updated periodically by querying Beaker API.

Tip:

It is possible to configure multiple pools for the same set of Beaker credentials, each with different avoid-groups list. For example:

# pool #1
avoid-groups:
  - laptops

# pool #2
avoid-groups:
  - generic-group-owning-machines-not-owned-by-any-other-group

This way, common guest requests can be routed to pool #1, while requests in the need of a special laptop HW would be routed to pool #2.

Beaker hostnames

To avoid provisioning particular machines, driver can be configured to avoid them.

Specification

avoid-hostnames:
  - hostname-1
  - hostname-2
  ...

Example

avoid-hostnames:
  # The following machines are not to be used for day-to-day jobs.
  - some.valuable.machine.com
  # This is a special laptop we do not want to use at all.
  - big-boss.foo.com

Each provisioning Beaker job would then contain a set of <hostname/> elements to instruct Beaker to avoid the listed machines.

Tip:

It is possible to configure multiple pools for the same set of Beaker credentials, each with different avoid-hostnames list. For example:

# pool #1
avoid-hostnames:
  - fancy1.foo.com
  - fancy2.foo.com

# pool #2
avoid-hostnames:
  # Can use fancyN machines, but...
  - not-so-fancy1.foo.com
  - not-so-fancy2.foo.com

Beaker pools

A pool can be pinned to use only a specific subset of Beaker machines by requesting them to belong to one or more Beaker pools.

Specification

pools:
  - poolname-1
  - poolname: poolname-2
  - poolname: poolname-3
    system-type: system-type-1
  ...

Example

pools:
  # Provision machines belonging to the following Beaker pools.
  - some-pool
  - another-pool
  - poolname: yet-another-pool
  # Same but with this pool, we need to use different system type for provisioning.
  - poolname: custom-laptops
    system-type: Laptop

Each provisioning Beaker job would then contain a set of <pool/> elements, with <system_type/> as needed, to instruct Beaker to pick only machines from specified pools.

Tip:

It is possible to configure multiple pools for the same set of Beaker credentials, each with different pools list. For example:

# pool #1
pools:
  - some-pool

# pool #2
pools:
  - some-pool
  # Can use fancy machines as well!
  - pool-with-very-fancy-machines

Distro variants

A compose can be mapped to a particular distro variant, Server, Workstation or any other offered by the distro. By default, no specific variant is requested from Beaker.

Specification

- 'compose1':          'distro1'
- 'compose1-Variant1': 'distro1;variant=Variant1'
- 'compose1-Variant2': 'distro1;variant=Variant2'

Example

# Basic mapping for Fedora Rawhide, Beaker will pick the default variant for us.
- 'Fedora-Rawhide': 'Fedora-Rawhide'
# For users interested in a particular variant, prepare composes with precise mapping.
- 'Fedora-Rawhide-Server': 'Fedora-Rawhide;variant=Server'
- 'Fedora-Rawhide-Everything': 'Fedora-Rawhide;variant=Everything'

When variant key is specified in the right-hand side of the image mapping, it is propagated to Beaker job via distro_variant element, to instruct Beaker to provide the given distro variant. Without the variant key, no distro_variant element is emitted.