Beaker driver



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

username: <string>
password: <string>
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.

  - group-1
  - group-2
  # 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.

Beaker hostnames

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

  - hostname-1
  - hostname-2
  # The following machines are not to be used for day-to-day jobs.
  # This is a special laptop we do not want to use at all.

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

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.

  - poolname-1
  - poolname: poolname-2
  - poolname: poolname-3
    system-type: system-type-1
  # 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.

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.

- 'compose1':          'distro1'
- 'compose1-Variant1': 'distro1;variant=Variant1'
- 'compose1-Variant2': 'distro1;variant=Variant2'
# 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.