Test Environment Installation

[guy9050]

Introduction

In order to provide the same experience across both the Continuous Integration (CI) systems and user environments, tmt has to take on responsibilities currently handled by Testing Farm. One critical task in this regard is the preparation of the guest environment.
Currently, the "guest setup" phase, which essentially involves executing a series of playbooks, is run only in CI by Testing Farm, thereby preventing users from replicating the precise CI workflow on their personal laptops.

Objective

To ensure a consistent experience across both the CI system and the user's laptop environment, it is necessary for tmt and the testing farm to align the execution of "guest setup" tasks. This alignment will simplify the replication of a CI workflow in local environments.

Open Questions

Method for Executing Playbooks via TMT

Approach: TMT cloning a dedicated repository containing the "guest setup" playbooks and executing them

pros:

• seems to be the simplest way of running playbooks.

cons:

• May require changes to tmt host machine, i.e. TF worker or user's laptop, and playbooks may run local commands

Approach: Leveraging Ansible Collections:

pros:

• It seems to be the standard approach for playbooks download and execution.

cons:

• May fail on dependencies or differences between Ansible versions installed in our users' laptops.
• May require changes to tmt host machine, i.e. TF worker or user's laptop, and playbooks may run local commands

Approach: Using Ansible execution environments:

pros:

• It allows you to have a customized image to run jobs, and each of them contain only what you need when running the job.
• It provides isolation being run from a container

cons:

• The creation of a Containerfile (resembling a Dockerfile) is necessary.
• The process of building or updating an execution environment has time costs.
• It requires this extra tool ansible-builder, and some registry(?) to host the image

Should each tmt profile (like "fedora-ci," "centos-stream-ci," etc.) have its own separate collections or execution environments for the guest setup?

• Such an arrangement would enable each team to independently manage their own "guest setup," facilitating quicker and independent application of hot-fixes.
• Some teams might refuse to take on this additional responsibility

[thrix]

@guy9050 from the discussion on tmt hacking:

• link the current playbooks from Testing Farm here
• the proposal is missing where would be the guest setup playbooks hosted (for bootstrapping)

[guy9050]

• https://gitlab.com/testing-farm/infrastructure/-/tree/testing-farm/ranch/redhat/citool-config/guest-setup
• Still TBD(?)

[thrix]

Next steps:

• For the next meeting, try to demonstrate the steps to bundle Testing Farm Public Ranch guest playbooks into an Ansible execution environment and run it manually against a tmt provisioned guest (container, ssh and localhost).
• Localhost (if it would be causing big trouble) is not a strict requirement
• What are the Ansible requirements for the Ansible execution environments, will it work well on RHEL9?
• Find out if the requirements for the target host (RHEL7+ is a must, RHEL6.10 is a nice to have)