action #151331
closed[qe-core][s390x][zvm] Make use of generic "s390x-zVM" class instead of s390x-zVM-vswitch-l2+l3+etc.
100%
Description
Motivation¶
Same as in #127523 now also for s390-zVM there is only a generic s390x-zVM worker class and no other variants for that.
Acceptance criteria¶
- AC1: All s390x z/VM tests use an openQA "machine definition" that uses the generic "s390x-zVM" worker class
- AC2: Current OSD openQA s390-zVM workers all have the generic class "s390x-zVM"
Suggestions¶
- Read #127523
- Verify common openQA tests can work on "s390x-zVM" worker class
- Use "s390x-zVM" in production job templates
- Remove "s390x-zVM-vswitch-l2" and other potential variants from https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls
Updated by okurz about 1 year ago
- Copied from action #127523: [qe-core][s390x][kvm] Make use of generic "s390-kvm" class to prevent too long waiting for s390x worker ressources added
Updated by okurz about 1 year ago
- Subject changed from [qe-core][s390x][zvm] Make use of generic "s390-zVM" class instead of s390x-zVM-vswitch-l2+l3+etc. to [qe-core][s390x][zvm] Make use of generic "s390x-zVM" class instead of s390x-zVM-vswitch-l2+l3+etc.
- Description updated (diff)
Updated by mgrifalconi about 1 year ago
There is no s390x-zVM
machine type on osd. Should I create one?
Or should I edit the current s390x-zVM-vswitch-l2
and s390x-zVM-vswitch-l3
to use
WORKER_CLASS=s390x-zVM
instead and not touch job groups?
Updated by okurz about 1 year ago
mgrifalconi wrote in #note-6:
There is no
s390x-zVM
machine type on osd. Should I create one?Or should I edit the current
s390x-zVM-vswitch-l2
ands390x-zVM-vswitch-l3
to use
WORKER_CLASS=s390x-zVM
instead and not touch job groups?
At best we can really change all tests to use a new machine type "s390x-zVM" which means either creating a new machine and moving over all schedule references to that or renaming "s390x-zVM-vswitch-l2" to "s390x-zVM" and applying some hardcore SQL to enforce the change and then adapt the test schedule accordingly. If you don't see that as feasible then use "s390x-zVM-vswitch-l2" with WORKER_CLASS=s390x-zVM
and get rid of all "s390x-zVM-vswitch-l3" references.
Updated by mgrifalconi about 1 year ago
Thanks Oliver for the explanation!
Let's do it in different steps:
- I just changed both
s390x-zVM-vswitch-l2
ands390x-zVM-vswitch-l3
to useWORKER_CLASS=s390x-zVM
. So in practice the switch is done - Will now give it a little time (couple of days) to check if anyone complains about something exploding. In that case we can quickly revert with little pain for the users
- Then we can create a new machine type with the correct name and ask people to migrate (will likely propose PRs where I can find job groups). This will just be cosmetics/cleanup change
Updated by mgrifalconi about 1 year ago · Edited
- qam-openqa-yml https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/merge_requests/675
- qa-sle-functional-userspace https://gitlab.suse.de/qe-core/qa-sle-functional-userspace/-/merge_requests/191
- qac-openqa-yaml https://gitlab.suse.de/qac/qac-openqa-yaml/-/merge_requests/1420
- qe-yam https://gitlab.suse.de/qe-yam/openqa-job-groups/-/merge_requests/19
Looking at loose ends and job groups unmanaged by git
Updated by mgrifalconi about 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
All migrated to s390x-zVM and s390x-zVM-vswitch-[l2,l3] deleted