action #119839
Updated by JERiveraMoya about 2 years ago
#### Observation
As follow-up of #115319 we didn't notice that for s390x zVM the same problem occurred because jobs didn't run on that time due to parent dependency.
These are the new failures found:
https://openqa.suse.de/tests/9842453#step/accept_license/2
https://openqa.suse.de/tests/9842454#step/accept_license/2
We don't want to target only those failures in this ticket but start to craft a default file for the whole arch/backend.
This is the list of jobs:
https://openqa.suse.de/tests/overview?arch=&flavor=&machine=s390x-zVM-vswitch-l2%2Cs390x-zVM-vswitch-l3&test=&modules=&module_re=&distri=sle&version=15-SP5&build=32.1&groupid=129#
This is the list of test suites in case the link would get outdated:
- select_modules_and_patterns+registration@s390x-zVM-vswitch-l2
- select_modules_and_patterns+registration@s390x-zVM-vswitch-l3
- autoyast_zvm_sles_product_reg@s390x-zVM-vswitch-l2
- guided_btrfs@s390x-zVM-vswitch-l2
- guided_btrfs@s390x-zVM-vswitch-l3
- guided_ext4@s390x-zVM-vswitch-l3
- guided_xfs@s390x-zVM-vswitch-l3
- minimal+base_yast@s390x-zVM-vswitch-l3
- ssh-X@s390x-zVM-vswitch-l3
- textmode@s390x-zVM-vswitch-l3
#### Acceptance criteria
**AC1**: Create a default yaml file for s390x zVM which can work with all the test suite listed above
**AC2**: Modify only schedules for s390x zVM to make them work with new created default
#### Suggestions
- If one schedule is used for several architecture, rather than modify, we can create a new schedule file for now to use keys instead of list of modules.
- Take inspiration from #115319
- For now there is not much thought about how the solution would work for test suites after installation, so let's focus on installation and consider the the other test suite, if it feasible we can try out, otherwise file a ticket for them.