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
To avoid provisioning machines owned by particular Beaker groups, driver can be configured to avoid them.
avoid-groups:
- group-1
- group-2
...
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.
To avoid provisioning particular machines, driver can be configured to avoid them.
avoid-hostnames:
- hostname-1
- hostname-2
...
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.
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.
pools:
- poolname-1
- poolname: poolname-2
- poolname: poolname-3
system-type: system-type-1
...
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.
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.
AVC denials during installation are a common issue that may appear in early development phases of development of new OS version. Beaker would mark an affected job as "failed", and, by default, Artemis would terminate the job and retry. failed-avc-result-patterns
and ignore-avc-on-compose-pattern
keys lets maintainers to detect such situations and specify composes for which a Beaker job may failed because of AVC denials and be still accepted.
failed-avc-result-patterns:
- <pattern1>
- <pattern2>
...
ignore-avc-on-compose-pattern: <pattern>
# All jobs where `/distribution/check-install` task fails because of AVC denials would be considered.
failed-avc-result-patterns:
- "/distribution/check-install:Fail:Completed:/10_avc_check:Fail"
# AVC denials appear when installing new Fedora 55, they will be fixed next week.
# For now, let users test their components.
ignore-avc-on-compose-pattern: "(?i)fedora-55"
failed-avc-result-patterns
specifies a list of patterns. If all of them match at least one task result, the job would be then checked against ignore-avc-on-compose-pattern
pattern. failed-avc-result-patterns
patterns are matched against a combination of task result fields: task name, task result, task status, phase name and phase result. Phase name and phase result may be empty strings if Beaker XML does not specify them.
For example, task results as reported in Beaker job result XML:
<task name="/distribution/check-install" result="Fail" status="Completed">
<result path="/distribution/check-install" result="Pass"/>
<result path="/10_avc_check" result="Fail"/>
<result path="/distribution/check-install/Sysinfo" result="Pass"/>
<task name="/distribution/reservesys" result="New" status="Running" >
<result path="/distribution/reservesys" result="Pass" />
would be converted into the following lines:
/distribution/check-install:Fail:Completed:/distribution/check-install:Pass
/distribution/check-install:Fail:Completed:/10_avc_check:Fail
/distribution/check-install:Fail:Completed:/distribution/check-install/Sysinfo:Pass
/distribution/reservesys:New:Running:/distribution/reservesys:Pass
With the help of installation-method-map
key, it is possible to specify a custom installation method in the case of need. The key holds a mapping between regular expressions, matching compose/distro, and corresponding methods. If the compose/distro of a request matches one of the patterns, its method is added to Beaker job XML.
Patterns are matched against a combination of multiple guest request properties: request compose and architecture, and corresponding Beaker distro and optionally its variant, if set. All four components are separated with a colon, :
. For example, a guest request for Fedora 55 on x86_64, mapped to Fedora-55-20240522.0
distro, would yield the following string for patterns to match: Fedora-55:x86_64:Fedora-55-20240522.0:Server
.
installation-method-map:
<pattern>: <string>
<pattern>: <string>
...
# There is a bug in Fedora 55 installation that requires HTTP method to be used.
installation-method-map:
"(?i)^fedora-55.*": "http"