QA » openQA Project » openQA Tests » qe-yam

PRs:
https://github.com/os-autoinst/openqa-trigger-from-obs/pull/160
https://github.com/openSUSE/openSUSE-release-tools/pull/2792

Additionally it required a couple of symlinks ln -s opensuse d-installer for new product under /var/lib/openqa/share/tests/.
an for needles in /var/lib/openqa/share/tests/d-installer/products/.
Example of both images bootin x86_64 and aarch64 (ignore what it is schedule):
https://openqa.opensuse.org/tests/2282629#step/bootloader/10
https://openqa.opensuse.org/tests/2282630#step/bootloader_uefi/10

Next steps:
comments from Marius:

isotovideo is overridden but as shown in the example it can be overridden with a containerized isotovideo. Of course this means that the container needs to contain isotovideo ...
... you can try it on one production worker first. Just tell us what you're doing before. If the setup is established it would make sense to update our salt configuration accordingly. (Likely all you need to do is to install docker/podman ensuring that the user _openqa-worker has the necessary rights to use them. Otherwise you wouldn't need to mess around with the worker host, I mean that's the point of using a container in the first place.)

Research about what is already done:
https://registry.opensuse.org/
https://progress.opensuse.org/projects/openqav3/wiki#o3-s390-workers
for example: devel/openqa/containers-tw/isotovideo

More info for next steps from @okurz:

Yes, I think having a container providing the test requirements is a good approach. Using the "new image" wizard in OBS it's really easy to build a new container to try that out. For later https://build.opensuse.org/project/show/devel:openSUSE:QA can be used to maintain non-personal container projects, e.g. QE Container and QE Core already do that there. I suggest to start with a local isotovideo-only run to get going. No need to use the openQA webUI to display results as long as nothing graphical is immediately required to get a test framework going. Any openQA test module can also be used to basically call any other command on the outside, e.g. an external test caller.

@Marius:

If isotovideo is not needed you don't have to use it. So you could instead invoke some other script which runs your tests using whatever framework you have in mind. However, the problem will be populating the worker's pool directory with all the artefacts you want to upload. The openQA worker expects a certain structure. There's unfortunately no good documentation. However, you can just run a job on a worker started with --no-cleanup and have a look at how the pool directory looks like afterwards.

I think test_order.json is quite important and likely you also need autoinst-status.json and base_state.json. Fortunately none of the files has a very complicated structure. Those files are usually created by isotovideo and are read/expected by the worker. So if you replace isotovideo then the replacement should create those files as well (and other artefacts as needed)

And if you replace isotovideo with a podman … command then I suppose you need to make sure that results created within the container end up in the pool directory outside the container, maybe by mounting the pool directory info the container (-v …)

@okurz (regarding no need to wrap each call with a container command when using containerazed isotovideo, assert_script_run can be used for example):

regarding "wrap each call": It could be as simple as booting a system using the usual methods from within os-autoinst-distri-opensuse and then call a single assert_script_run on your test runner, not multiple calls.