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 almost 7 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 almost 7 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 almost 7 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 almost 7 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 almost 7 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 almost 7 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 almost 7 years ago
- Status changed from Workable to In Progress
- Assignee changed from michalnowak to JERiveraMoya
Updated by JERiveraMoya almost 7 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 almost 7 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 almost 7 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 almost 7 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 almost 7 years ago
- Status changed from In Progress to Resolved
Changes are done in OSD.