Project

General

Profile

Actions
Copy link

action #119890

closed

coordination #119836: [epic] Convert YAML schedules for YaST to be based on YAML default files

Create default yaml files for the other backends of x86_64 and adapt test suites to use them in YaST group

Added by JERiveraMoya about 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
rainerkoenig
Target version:
Current
Start date:
2022-11-04
Due date:
% Done:

0%

Estimated time:

Description

Observation

We have a default file called default.yaml to represents default for x86_64 64bit, but still we run some other bakends in YaST job group in openQA.
In this ticke we will cover uefi,svirt-xen-hvm,svirt-xen-pv

This is the list of jobs:
https://openqa.suse.de/tests/overview?arch=x86_64&flavor=&machine=uefi%2Csvirt-xen-hvm%2Csvirt-xen-pv&test=&modules=&module_re=&distri=sle&version=15-SP5&build=32.1&groupid=129#
Filter in openQA by Machines: uefi,svirt-xen-hvm,svirt-xen-pv to get the list of modules for latest build in case the link got outdated.

Acceptance criteria

AC1: Create new default yaml files for each non-64bit x86_64 backend to be used by all the test suite listed above
AC2: Modify only schedules for x86_64 with backend uefi,svirt-xen-hvm,svirt-xen-pv to make them work with new created defaults

Suggestions

  • If one schedule is used for several architecture/backend, rather than modify it, we can create a new schedule file for now using keys instead of list of modules.
  • Take inspiration from other tasks done in Epic where this task belongs.
  • 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 rest of test suite, if it feasible we can try out, otherwise file a ticket for them.
Actions
Copy link
 #1

Updated by JERiveraMoya about 2 years ago

  • Tags set to qe-yast-refinement
Actions
Copy link
 #2

Updated by JERiveraMoya about 2 years ago

  • Tags deleted (qe-yast-refinement)
Actions
Copy link
 #3

Updated by rainerkoenig about 2 years ago

  • Status changed from Workable to In Progress
  • Assignee set to rainerkoenig
Actions
Copy link
 #4

Updated by rainerkoenig about 2 years ago

A search for "uefi,svirt-xen-hvm,svirt-xen-pv" on x86_64 architecture in Build 42.5 shows the following tests in the YaST group (groupID=129):

Flavor Full

  • USBinstall@uefi
  • select_modules_and_patterns+registration@uefi

Flavor Online

  • USBinstall@uefi
  • autoyast_non_secure_boot@uefi
  • create_hdd_gnome_libyui@svirt-xen-hvm
  • crypt_no_lvm@uefi
  • cryptlvm@uefi
  • gpt@uefi
  • guided_ext4@svirt-xen-hvm
  • guided_ext4@svirt-xen-pv
  • guided_ext4@uefi
  • guided_xfs@svirt-xen-hvm
  • guided_xfs@svirt-xen-pv
  • lvm+RAID1@svirt-xen-hvm
  • lvm+RAID1@svirt-xen-pv
  • lvm+RAID1@uefi
  • mediacheck@svirt-xen-hvm
  • minimal+base_yast@svirt-xen-hvm
  • minimal+base_yast@svirt-xen-pv
  • msdos@svirt-xen-hvm
  • msdos@svirt-xen-pv
  • nvme@uefi
  • textmode@svirt-xen-hvm
  • textmode@svirt-xen-pv

Some tests were already migrated in the PoC ticket #106847, so they are striked out in the list above.

Actions
Copy link
 #5

Updated by JERiveraMoya almost 2 years ago

please, don't strike out (exclude) anything, those were migrated with flows for first iteration, but now we want to do it with defaults without flows.

Actions
Copy link
 #6

Updated by rainerkoenig almost 2 years ago

Status update

Doing another approach, one PR/MR for each backend, starting with svirt-xen-pv now.

Assuming that in the long term we want to get rid of the YAML_SCHEDULE_FLOWS this means that the schedules that were migrated in the PoC for the new scheduler need to be adapted.

guided_xfs.yaml just needs some extra lines that would otherwise come from flows. They shouldn't harm even if flows are still defined for other backends.

guided_ext4.yaml is quite different because it has a test_data section in the YAML_SCHEDULE:

test_data:
  guided_partitioning:
    filesystem_options:
      root_filesystem_type: ext4
  <<: !include test_data/yast/ext4/ext4.yaml

Test data for svirt-xen would be test_data/yast/ext4/ext4_xen.yaml which differs in the name for the block devices (vda vs xvda).

To unify the YAML_SCHEDULE the solution would be to define TEST_DATA on job group level. The part with root_filesystem_type: ext4 can be deleted because we already use installation/partitioning/guided_setup/select_filesystem_option_ext4 in the schedule which does exactly the same.

Actions
Copy link
 #8

Updated by rainerkoenig almost 2 years ago

Working on the svirt-xen-hvm backend

Migrated schedules that passed the VR:

  • lvm+RAID1
  • textmode

Schedules that were not migrated:

  • yast2_gui (chained dependency, uses qcow instead of installing)
  • yast2_ncurses_textmode (testsuite is taking a qcow instead of installing)
  • mediacheck (too short to convert, excluded hooks would make this less readable)
Actions
Copy link
 #9

Updated by openqa_review almost 2 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: guided_ext4@svirt-xen-hvm
https://openqa.suse.de/tests/10226812#step/validate_blockdevices/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions
Copy link
 #10

Updated by JERiveraMoya over 1 year ago

  • Status changed from In Progress to Resolved
Actions
Copy link

Also available in: Atom PDF