Containers: fix schedule for JeOS #13672
Conversation
|
Please be aware of this proposal: #13668 |
i am not sure any more. i have a few observations. they are minor atm because i think it is more important to solve the issue. So in theory we can just merge this and discuss further later. However still cant decide as this PR seems to require additional commit for the variables you mentioned. ping me whenever you want |
To fix the scheduling issue, no new PRs are needed. The variables will be set in the UI. Can you have a look at validate_btrfs test? Any ideas why it fails? |
|
VR to make sure default JeOS schedule is not modified: |
|
Related to: #13645 |
|
Ok, wait. This change breaks these tests: But I would say that the job setup for this test is completely wrong. It's booting a CentOS HDD using JeOS flavor... I guess we need to change that, create a new flavor or re-use existing one... |
|
IMO, we should use this test to run the container tests after hdd creation and maybe place them in Leap 15.3 Updates job instead of Leap 15.3 images. |
|
| @@ -80,7 +80,7 @@ sub load_host_tests_docker { | |||
| loadtest 'containers/registry' if is_x86_64; | |||
| loadtest 'containers/docker_compose'; | |||
| } | |||
| loadtest 'containers/validate_btrfs' if is_x86_64; | |||
| loadtest 'containers/validate_btrfs' if (is_x86_64 && !is_jeos); | |||
There was a problem hiding this comment.
This module is not executed in SLE JeOS either, so I created this ticket to enable it later on.
https://progress.opensuse.org/issues/102377
|
My idea is to reorder the O3 test like this:
http://fromm.arch.suse.de/tests/overview?distri=opensuse&version=15.3&build=9.279&groupid=50 This would also need like this: |
|
@Vogtinator @DimStar77 Would you be ok with my proposal to group container image tests so everything looks more tidy? |
Yes! That was pretty much the goal from the beginning, but implementing that in openqa-trigger-from-obs isn't trivial (See discussion on os-autoinst/openqa-trigger-from-obs#145), particularly because of It would be possible to decouple container images into a separate project, but that is arguably overkill and makes it harder (if not practically impossible) to use latest JeOS as host, which is simpler and quicker than using a GM image + installing updates. |
|
The following ticket has been resolved: https://progress.opensuse.org/issues/97958 This is ready to be merged. |
This fixes:
https://progress.opensuse.org/issues/102272
https://progress.opensuse.org/issues/102278
This basically enables running the default jeos tests as it was done before, and then run the specific container tests.
In a follow-up PR, we could come up with a more smart default jeos test for container jobs only, instead of running all the default ones, but this is a different topic than this PR tries to fix.
VRs:
Some things need to be done in job configuration:
NUMDISKS=2forvalidate_btrfstestBOOT_HDD_IMAGE-> JeOS tests don't need that variable.CONTAINERS_UNTESTED_IMAGES-> this is a HOST test based to test container tools and packages on JeOS. We already have a job to validate the "untested" container image: https://openqa.opensuse.org/tests/2029146. If we want to enable also container image validation on JeOS, we should create a separate job.