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 title: Manual Install of OpenQA for rockylinux
author: Alan Marshall author: Alan Marshall
revision_date: 2023-05-03 revision_date: 2024-04-25
rc: rc:
prod: Rocky Linux prod: Rocky Linux
level: Draft 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 ## Step-by-step Install Guide
OpenQA can be installed only on a Fedora (or OpenSUSE) server or workstation. OpenQA can be installed only on a Fedora (or OpenSUSE) server or workstation.
Tested on Fedora 40 Server
``` ```
# install Packages # install Packages
# for openqa # for openqa
sudo dnf install openqa openqa-httpd openqa-worker fedora-messaging python3-jsonschema sudo dnf install -y openqa openqa-httpd openqa-worker fedora-messaging python3-jsonschema
sudo dnf install perl-REST-Client.noarch sudo dnf install -y perl-REST-Client.noarch
# and for createhdds # and for createhdds
sudo dnf install libguestfs-tools libguestfs-xfs python3-fedfind python3-libguestfs sudo dnf install -y libguestfs-tools libguestfs-xfs python3-fedfind python3-libguestfs
sudo dnf install libvirt-daemon-config-network libvirt-python3 virt-install withlock sudo dnf install -y libvirt libvirt-daemon-config-network libvirt-python3 virt-install withlock
# configure httpd: # configure httpd:
cd /etc/httpd/conf.d/ cd /etc/httpd/conf.d/
@ -47,8 +48,7 @@ sudo setsebool -P httpd_can_network_connect 1
sudo systemctl restart httpd sudo systemctl restart httpd
# configure the web UI # configure the web UI
sudo vi /etc/openqa/openqa.ini sudoedit /etc/openqa/openqa.ini
[global] [global]
branding=plain branding=plain
download_domains = rockylinux.org download_domains = rockylinux.org
@ -77,7 +77,7 @@ sudo systemctl restart httpd
# Click Login, then Manage API Keys, create a key and secret. # Click Login, then Manage API Keys, create a key and secret.
# insert key and secret # insert key and secret
sudo vi /etc/openqa/client.conf sudoedit /etc/openqa/client.conf
[localhost] [localhost]
key = ... 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 sudo chown -R geekotest:geekotest rocky
cd rocky cd rocky
# when working in /var/lib/openqa nearly all commands need sudo so it is # when working in /var/lib/openqa nearly all commands need sudo.
# 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
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 # or whichever branch has the latest updates for your tests
./fifloader.py -l -c templates.fif.json templates-updates.fif.json sudo ./fifloader.py -l -c templates.fif.json
git clone https://github.com/rocky-linux/createhdds.git ~/createhdds sudo git clone https://github.com/rocky-linux/createhdds.git ~/createhdds
mkdir -p /var/lib/openqa/share/factory/hdd/fixed sudo mkdir -p /var/lib/openqa/share/factory/hdd/fixed
# will need about 200GB disk space available for ongoing tests # will need about 200GB disk space available for ongoing tests
cd /var/lib/openqa/factory/hdd/fixed cd /var/lib/openqa/factory/hdd/fixed
# start a long running process that provides hdd image files for ongoing tests # 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 # get Rocky iso files for testing from staging repository
mkdir -p /var/lib/openqa/share/factory/iso/fixed sudo mkdir -p /var/lib/openqa/share/factory/iso/fixed
cd /var/lib/openqa/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 sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-boot.iso
curl -LOR https://dl.rockylinux.org/pub/rocky/9/isos/x86_64/Rocky-9.1-x86_64-minimal.iso sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-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-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 # post tests and view progress on webui
cd /var/lib/openqa/tests/rocky/ 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 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
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-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. 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 ### Helper Scripts
@ -139,7 +147,7 @@ cancel-build.sh is especially useful when you discover that you have initiated a
### Using Templates ### Using Templates
#### Problem #### 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: 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: