action #32440
closed[sle][functional][u][easy] Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware
0%
Description
skip_registration test suite has following PUBLISH_HDD_1: SLES-%VERSION%-%ARCH%-%BUILD%_unregistered.qcow2.
The problem is that without %MACHINE% it won't distinguish various Xen & Hyper-V machines which differ significantly.
I intend to change PUBLISH_HDD_1 to: SLES-%VERSION%-%ARCH%-Build%BUILD%@%MACHINE%-unregistered.qcow2, which should be somewhat in line with other publishing test suites.
Updated by michalnowak about 6 years ago
- Subject changed from Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware to [functional] Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware
Updated by michalnowak about 6 years ago
Following test suites are consuming image from skip_registration: minimal+proxy_SCC-postreg_yast_scc & minimal+proxy_SCC-postreg_SUSEconnect. And only the latter is scheduled in SLE:Functional. They both need to be adapted to the change.
Updated by michalnowak about 6 years ago
And while at it... The problem with minimal+proxy_SCC-postreg_SUSEconnect on 64bit machine failing "randomly" is likely that is uses whatever image is present at the moment, be it e.g. image from uefi or Xen PV machine.
Updated by michalnowak about 6 years ago
There are six jobs of skip_registration on s390x all publishing image as SLES-15-s390x-%BUILD%_unregistered.qcow2, effectively overwriting the image, and not consuming the image in minimal+proxy_SCC-postreg as s390x is not scheduled for that test suite. Fixing PUBLISH_HDD_1 means for s390x that 6 different images will be stored on NFS, but not being used.
Updated by okurz about 6 years ago
true. I guess scheduling an image creation job and not scheduling any consumer is the culprit. How about specific test suites for testing and ones that focus on publishing including all downstream scenarios?
Updated by michalnowak about 6 years ago
- Related to action #32689: [sle][functional][fast][u] test fails in boot_to_desktop: Unable to switch from login_shell to gnome session added
Updated by JERiveraMoya about 6 years ago
- Status changed from Workable to In Progress
- Assignee changed from michalnowak to JERiveraMoya
Updated by JERiveraMoya about 6 years ago
Changed setting PUBLISH_HDD_1 in OSD for parent job skip_registration and both chained children: minimal+proxy_SCC-postreg_SUSEconnect and minimal+proxy_SCC-postreg_yast_scc
any other thing to do here? @michalnowak?
Updated by JERiveraMoya about 6 years ago
- Subject changed from [functional] Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware to [sle][functional] Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware
Updated by okurz about 6 years ago
- Subject changed from [sle][functional] Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware to [sle][functional][u] Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware
- Due date set to 2018-03-27
- Target version set to Milestone 15
Adding to current sprint as I assume this is already ongoing.
Updated by nicksinger about 6 years ago
- Subject changed from [sle][functional][u] Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware to [sle][functional][u][easy] Change PUBLISH_HDD_1 of skip_registration test suite to be MACHINE aware
Updated by JERiveraMoya about 6 years ago
- Status changed from In Progress to Resolved
Changes are done in OSD.