OpenQA

Current openQA implementations do not offer a local user management method. This is why I use kanidm as a local identity management platform which is used for user management on my own openQA development instance. This is certainly overkill for most users and I only use it because I like kanidm and because all bits and bolts run locally on a single openQA instance.

In OpenQA one has often to check the output of a command. Now most of us think foremost “this is a task for my beloved grep”:

When updating the dependencies.yaml file in os-autoinst, e.g. when you’d like to fix the outdated perltidy version in the repo the recommended workflow is to:

• Update dependencies.yaml
• Run make update-deps

This will update the cpanfile for you and you only need to make your changes in one single file (dependencies.yaml).

Due to recent changes in the worker configuration of the SUSE internal openQA instance, we needed to reconfigure some of the PowerPC jobs in openQA. This triggered a couple of questions regarding the availability of openQA worker, worker backends, their differences and their caveats. This blog post should act as a quickstart/overview guide for people getting into OpenQA testing on the PowerPC architecture.

openqa-mq is a small CLI tool that receives openQA related events from RabbitMQ. It is part of the openqa-mon packages and will work for OSD and for OOO.

A coworker recently faced the problem to copy&pasting a large amount of text into a VNC terminal for openQA. VNC doesn’t always allow copy&paste and when you have to manually type a longer string this is prone to typos and human error.

I recently automated the installation of updates on my openQA development instance. The goal was to make the instance updates itself over night, but only if it is idle, i.e. there are no running jobs. Sometimes when I’m busy, the instance needs to work overnight and despite openQA being able to restart cancelled jobs from a reboot, I prefer to avoid situations where this might result in problems in times, where I really can’t have that.

I recently encountered a new interesting openQA issue:

[2023-03-13T14:18:22.651705+01:00] [warn] [pid:18929] !!! : qemu-system-x86_64: -netdev tap,id=qanet0,ifname=tap3,script=no,downscript=no: could not configure /dev/net/tun (tap3): Operation not permitted

This is an error that you likely are encountering on a older openQA instance, after you setup multimachine jobs but haven’t used them in a while. For me the solution was to grant the CAP_NET_ADMIN capabilities to the qemu binary (again):

When developing new openQA tests you will have to run a lot of verification and debug test runs. This is why I typically encourage people to do all openQA testing on their own instances, to prevent spamming of the production instances.

The openqa-revtui tool is a neat CLI utility for helping you review openQA jobs and job groups. It is part of the openqa-mon project, which has grown in the last years and now consists on more than the job monitoring tool itself.