Update Step-by-step section for Fedora 40

This commit is contained in:
Alan Marshall 2024-04-26 10:17:43 +01:00
parent 5ba6c3ed86
commit cbbd6cbb90
Signed by: alangm
GPG Key ID: 4DF85D1B967F51A6

View File

@ -1,7 +1,7 @@
---
title: Manual Install of OpenQA for rockylinux
author: Alan Marshall
revision_date: 2023-05-03
revision_date: 2024-04-25
rc:
prod: Rocky Linux
level: Draft
@ -28,16 +28,17 @@ Some pages use queries to select what should be shown. The query parameters are
## Step-by-step Install Guide
OpenQA can be installed only on a Fedora (or OpenSUSE) server or workstation.
Tested on Fedora 40 Server
```
# install Packages
# for openqa
sudo dnf install openqa openqa-httpd openqa-worker fedora-messaging python3-jsonschema
sudo dnf install perl-REST-Client.noarch
sudo dnf install -y openqa openqa-httpd openqa-worker fedora-messaging python3-jsonschema
sudo dnf install -y perl-REST-Client.noarch
# and for createhdds
sudo dnf install libguestfs-tools libguestfs-xfs python3-fedfind python3-libguestfs
sudo dnf install libvirt-daemon-config-network libvirt-python3 virt-install withlock
sudo dnf install -y libguestfs-tools libguestfs-xfs python3-fedfind python3-libguestfs
sudo dnf install -y libvirt libvirt-daemon-config-network libvirt-python3 virt-install withlock
# configure httpd:
cd /etc/httpd/conf.d/
@ -47,8 +48,7 @@ sudo setsebool -P httpd_can_network_connect 1
sudo systemctl restart httpd
# configure the web UI
sudo vi /etc/openqa/openqa.ini
sudoedit /etc/openqa/openqa.ini
[global]
branding=plain
download_domains = rockylinux.org
@ -77,7 +77,7 @@ sudo systemctl restart httpd
# Click Login, then Manage API Keys, create a key and secret.
# insert key and secret
sudo vi /etc/openqa/client.conf
sudoedit /etc/openqa/client.conf
[localhost]
key = ...
@ -94,40 +94,48 @@ sudo git clone https://github.com/rocky-linux/os-autoinst-distri-rocky.git rocky
sudo chown -R geekotest:geekotest rocky
cd rocky
# when working in /var/lib/openqa nearly all commands need sudo so it is
# easier to su to root. If desired sudo per command can be used instead.
sudo su
git config --global --add safe.directory /var/lib/openqa/share/tests/rocky
# when working in /var/lib/openqa nearly all commands need sudo.
git checkout develop
sudo git config --global --add safe.directory /var/lib/openqa/share/tests/rocky
sudo git checkout develop
# or whichever branch has the latest updates for your tests
./fifloader.py -l -c templates.fif.json templates-updates.fif.json
git clone https://github.com/rocky-linux/createhdds.git ~/createhdds
mkdir -p /var/lib/openqa/share/factory/hdd/fixed
sudo ./fifloader.py -l -c templates.fif.json
sudo git clone https://github.com/rocky-linux/createhdds.git ~/createhdds
sudo mkdir -p /var/lib/openqa/share/factory/hdd/fixed
# will need about 200GB disk space available for ongoing tests
cd /var/lib/openqa/factory/hdd/fixed
# start a long running process that provides hdd image files for ongoing tests
~/createhdds/createhdds.py all
~/createhdds/createhdds.py -t -b stg all
# get Rocky iso files for testing
mkdir -p /var/lib/openqa/share/factory/iso/fixed
# get Rocky iso files for testing from staging repository
sudo mkdir -p /var/lib/openqa/share/factory/iso/fixed
cd /var/lib/openqa/factory/iso/fixed
curl -LOR https://dl.rockylinux.org/pub/rocky/9/isos/x86_64/Rocky-9.1-x86_64-boot.iso
curl -LOR https://dl.rockylinux.org/pub/rocky/9/isos/x86_64/Rocky-9.1-x86_64-minimal.iso
curl -LOR https://dl.rockylinux.org/pub/rocky/9/isos/x86_64/Rocky-9.1-x86_64-dvd.iso
sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-boot.iso
sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-minimal.iso
sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-dvd.iso
sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/CHECKSUM
sha256sum -c CHECKSUM
# fix ownership, add <user> to group, reboot
cd /var/lib/openqa/factory/
sudo chown -R geekotest:geekotest ./
sudo usermod -aG geekotest <user>
sudo init 6
# post tests and view progress on webui
cd /var/lib/openqa/tests/rocky/
openqa-cli api -X POST isos ISO=Rocky-9.1-x86_64-minimal.iso ARCH=x86_64 DISTRI=rocky FLAVOR=minimal-iso VERSION=9.1 BUILD="$(date +%Y%m%d.%H%M%S).0"-minimal
openqa-cli api -X POST isos ISO=Rocky-9.1-x86_64-boot.iso ARCH=x86_64 DISTRI=rocky FLAVOR=boot-iso VERSION=9.1 BUILD="$(date +%Y%m%d.%H%M%S).0"-boot
sudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-minimal.iso ARCH=x86_64 DISTRI=rocky FLAVOR=minimal-iso VERSION=9.3 BUILD="$(date +%Y%m%d.%H%M%S).0"-minimal
sudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-boot.iso ARCH=x86_64 DISTRI=rocky FLAVOR=boot-iso VERSION=9.3 BUILD="$(date +%Y%m%d.%H%M%S).0"-boot
```
At this point your system is configured for single vm deployment and it can be used as such. Pause here if you wish to get some practice using openqa before progressing further.
Facilities for multi-vm testing which is substantially more complicated is beyond the scope of this document.
Installation of facilities for multi-vm testing which is substantially more complicated is beyond the (present) scope of this document.
### Helper Scripts
@ -139,7 +147,7 @@ cancel-build.sh is especially useful when you discover that you have initiated a
### Using Templates
#### Problem
A problem arises when testing an operating system, especially when doing continuous testing, that there is always a certain combination of jobs, each one with its own settings, that needs to be run for every revision. Those combinations can be different for different 'flavors' of the same revision, like running a different set of jobs for each architecture. This combinational problem can go one step further if OpenQA is being used for different kinds of tests, like running some simple pre-integration tests for some snapshots combined with more comprehensive post-integration tests for release candidates.
One of the problems that arises when testing an operating system, especially when doing continuous testing, is that there is always a certain combination of jobs, each one with its own settings, that needs to be run for every revision. These combinations can be different for different 'flavors' of the same revision, like running a different set of jobs for each architecture. This combinational problem can go one step further if OpenQA is being used for different kinds of tests, like running some simple pre-integration tests for some snapshots combined with more comprehensive post-integration tests for release candidates.
This section describes how an instance of OpenQA *could* be configured using the options in the admin area of the webUI to automatically create all the required jobs for each revision of your operating system that needs to be tested. *If* you were starting from scratch (the difficult way), you would probably go through the following order: