QA (public) » openQA Project (public)

• This use-case is also impaired by the inability to use custom needles (https://progress.opensuse.org/issues/56789 #56789).
• Besides, the implementation suggestion use SCHEDULE parameter with e.g. SCHEDULE=tests/boot/boot_to_desktop,tests/run_custom implies that a composability of test distributions would be required. This is of course possible by somehow embedding the base test distribution (e.g. os-autoinst-distri-opensuse) into the product repository (e.g. cobbler) adding own tests on top of it. But this sounds rather hacky and inconvenient to use. So having a light test distribution which can simply be referred to as "base test distribution" seems a desirable for this use-case.

These points are likely the tricky part. Triggering the test execution itself is likely not that hard. Instead of writing a "polling bot" I would add an API route in openQA which can be added as GitHub hook.

mkittler wrote:

• This use-case is also impaired by the inability to use custom needles (https://progress.opensuse.org/issues/56789 #56789).

Maybe we can still consider any need for needles an independant requirement of the part about triggering test code which I find more important.

Regarding the "hacky approach" or "base test distribution" I think we have a ticket for having something like a "linux" middleware between os-autoinst and os-autoinst-distri-opensuse that can be extracted but for now and to have a proof-of-concept on which to improve upon I recommend the "hacky" approach

[…] I would add an API route in openQA which can be added as GitHub hook.

What would you add as an API route here?

okurz wrote:

[…]
5. Allow to compute the HDD image path dynamically, e.g. by providing a regex which is matched against existing assets on the openQA instance. This would allow utilizing an existing image in a dynamic way (e.g. to use the image created by the installation job for the most latest Tumbleweed snapshot as the openQA-in-openQA test does).

For now I don't think this is necessary as one can use a static link to an appliance, e.g. http://download.opensuse.org/tumbleweed/appliances/openSUSE-Tumbleweed-Minimal-VM.x86_64-kvm-and-xen.qcow2

okurz wrote:

okurz wrote:

[…]
5. Allow to compute the HDD image path dynamically, e.g. by providing a regex which is matched against existing assets on the openQA instance. This would allow utilizing an existing image in a dynamic way (e.g. to use the image created by the installation job for the most latest Tumbleweed snapshot as the openQA-in-openQA test does).

For now I don't think this is necessary as one can use a static link to an appliance, e.g. http://download.opensuse.org/tumbleweed/appliances/openSUSE-Tumbleweed-Minimal-VM.x86_64-kvm-and-xen.qcow2

How? This is an external URL. You're quoting a use case for re-using the image generated by a job.

cdywan wrote:

How? This is an external URL. You're quoting a use case for re-using the image generated by a job.

There was never a strong need to re-use an openQA generated image though.

@okurz, I'm having a hard time trying to understand the next step for this story. What are the next three steps to move this forward? (regardless of when, but I'm looking for order of steps, represented in tickets)

Also, because I don't really want to reopen #150992:

Trying to understand the failure rate of #150992 and other consequences in the context of recent slack chat, I came to notice at least one 503 (bad gateway), which reminds me of the problems I already mentioned to you, while discussing #154798

That sleep 1, is needed, as otherwise the webUI will return 503's constantly

And before moving any further, somehow that has to be addressed, which brings me again to the question of how we track usage statistics and monitor the web UI health. iirc either mojolicious ui that was showing some stats, @kraih you recall maybe or how we solved the similar problem we were having years ago, I think it was by incrementing something with the webui workers/processes and so on?
https://github.com/os-autoinst/os-autoinst-distri-opensuse/actions/runs/7666441613/job/20894254516#step:5:143

szarate wrote in #note-25:

@okurz, I'm having a hard time trying to understand the next step for this story. What are the next three steps to move this forward? (regardless of when, but I'm looking for order of steps, represented in tickets)

The next steps are the subtasks in this ticket here, e.g. #130934 and #152939 currently in the backlog.
After those the other open subtasks or what comes up based on our experiences with those from production.

Also, because I don't really want to reopen #150992:
[...] I came to notice at least one 503 (bad gateway)

Yes, that's a known behavior. "Bad gateway" is a bit misleading but hard to avoid. In this context here it shouldn't ever be a problem as there is retrying and the final result is monitored for anyway.

which reminds me of the problems I already mentioned to you, while discussing #154798

Yes, I would like to solve such 503's as part of that

okurz wrote in #note-26:

szarate wrote in #note-25:

@okurz, I'm having a hard time trying to understand the next step for this story. What are the next three steps to move this forward? (regardless of when, but I'm looking for order of steps, represented in tickets)

The next steps are the subtasks in this ticket here, e.g. #130934 and #152939 currently in the backlog.
After those the other open subtasks or what comes up based on our experiences with those from production.

Also, because I don't really want to reopen #150992:
[...] I came to notice at least one 503 (bad gateway)

Yes, that's a known behavior. "Bad gateway" is a bit misleading but hard to avoid. In this context here it shouldn't ever be a problem as there is retrying and the final result is monitored for anyway.

which reminds me of the problems I already mentioned to you, while discussing #154798

Yes, I would like to solve such 503's as part of that
Much clear now <3 appreciate the clarity