Frequently Asked Questions

How to look up machines in Beaker provisioned by Testing Farm?

Testing Farm exposes the artifacts URL in the job whiteboard, e.g. https://artifacts.osci.redhat.com/testing-farm/18b7a17a-2158-48ea-91a1-65b4dabd980c. Go to Beaker Jobs and search using the artifacts URL or the Testing Farm request ID. If the search does not return any jobs, Testing Farm has either not started provisioning yet or is provisioning resources on a different infrastructure, e.g. AWS.

How to find previous Testing Farm requests?

If you’ve lost the UUID of a previous request or the link to list your requests, you can retrieve them using the API:

First, find your user/token ID using the whoami endpoint:
```
$ http -A bearer -a $TESTING_FARM_API_TOKEN https://api.testing-farm.io/v0.1/whoami
```
Look for the id field in the token section of the response.

Then list your requests for the last 7 days:

$ http "https://api.testing-farm.io/v0.1/requests?token_id=97c77906-f223-499d-b1d1-e98f9a2d1de1&created_after=$(date -Idate -d "7 days ago")"

Replace 97c77906-f223-499d-b1d1-e98f9a2d1de1 with your actual token ID from step 1.

You can adjust the created_after parameter to look further back in time if needed.

How does Testing Farm handle the `tmt` provision step?

Testing Farm behaves differently for the default single-host pipeline and the multi-host pipeline.

Single-host Pipeline (default)

This is the default pipeline used by Testing Farm, i.e. it is run if you do not specify the settings.pipeline field in the API.

In the single-host pipeline, the provision step is overridden with how: artemis and the provisioning details are specified in the API request. The provision.hardware field is honored; others are ignored. The hardware field from the API always overrides the one from the plan — there is no merging.

Let’s take this simple plan as an example:

provision:
  how: virtual
  image: Fedora
  hardware:
    memory: >= 4Gi

execute:
  how: tmt

And this Testing Farm request using the above plan:

testing-farm request --compose Fedora-Rawhide --hardware 'disk.size=>100Gi'

The provisioned machine will have these properties:

Please note that there is no actual provision step generated. Testing Farm calls Artemis directly; this is just for illustration.

Please note that hardware requirements from the API take precedence. There is no merging with the hardware requirements in the plan.

provision
   how: artemis
   image: Fedora-Rawhide
   hardware:
     disk:
       - size >= 100Gi

Multi-host Pipeline

In the multi-host pipeline, the how field is fully respected. Testing Farm uses tmt’s --update-missing functionality to fill in missing details from the API provision data. This often requires adjusting the provision plan using context variables so it can run both locally and in the multi-host pipeline.

Consider this simple multi-host plan:

provision:
  - name: client
    how: virtual
    image: Fedora-41

  - name: server
    how: virtual
    image: Fedora-42

execute:
  how: tmt

And this Testing Farm request using the above plan:

testing-farm request --compose Fedora-Rawhide --pipeline-type tmt-multihost

This plan will fail because Testing Farm honors what is in the plan, and the virtual provisioner is not supported on Testing Farm workers. The compose value will also be ignored because the image is already specified in the plan, and that takes precedence.

To fix this, remove the how from the plan. Testing Farm will then apply its own provisioning method (e.g. how: artemis). Also, remove the image where you want it to be updated from the request.

provision:
  - name: client

  - name: server
    image: Fedora-42

execute:
  how: tmt

With this change, Testing Farm will populate how and image for the client using the API.

provision:
  - name: client
    how: artemis
    image: Fedora-Rawhide

  - name: server
    how: artemis
    image: Fedora-42

execute:
  how: tmt

How to exclude artifacts from installing

Testing Farm installs artifacts specified in the environments[].artifacts field in the API before running tmt. If you want to skip this installation but still have the artifacts available on the system via a repository, add the following prepare step in your tmt plan.

prepare:
  - name: Skip Testing Farm installation of artifacts
    how: install
    excludes:
      - .*

How to reserve a machine in FIPS mode?

Testing Farm supports reserving machines with FIPS mode enabled. This requires using the --tmt-prepare option to configure FIPS during the prepare phase.

For more details, see the Reserve Machine in FIPS Mode section.

testing-farm CLI

$ testing-farm reserve --tmt-prepare="--insert --order 0 --how feature --fips enabled" --compose RHEL-10.0-Nightly

How are hardware requirements handled when specified via the API and in the `tmt` plan?

Hardware requirements specified in the API request will completely override hardware requirements from the tmt plan. There is no merging of hardware requirements - the API specification replaces the plan specification entirely.

For example, if you have a plan with these hardware requirements:

provision:
  hardware:
    memory: >= 4Gi
    cpu:
      processors: >= 2

And submit a Testing Farm request with:

testing-farm request --hardware 'disk.size=>100Gi'

The final provisioned machine will only have the disk size requirement from the API request. The memory and CPU requirements from the plan will be ignored.

To include all requirements, specify them in the API request:

testing-farm request --hardware 'memory=>= 4Gi' --hardware 'cpu.processors=>= 2' --hardware 'disk.size=>100Gi'