action #121906
closedcoordination #120534: [epic] Provide auto-installation test suites for supporting testing
Create a default+gnome daily auto-installation for SLE 15 SP4
0%
Description
Motivation¶
It was found a failed test case on remote_vnc_target_nfs caused by outdated image and incompatible vnc between the version in support server and the version of product validation
https://openqa.suse.de/tests/10037128
see openqa_support_server_sles15sp2_x86-64_gnome.qcow2
Yam squad will solve this issue with a two-steps-approach:
(1) Creating a fresh image for SLE 15 SP4 using AutoYaST that could be use in near future for migration to have patched system.
(2) Creating a test suite to configure support server based on previous image generated by AutoYaST.
Acceptance criteria¶
AC1: Create a daily auto-installation for SLE 15 SP4 with gnome and the rest default
Additional information¶
It is chosed SLE 15 SP4 because the version delta should be smaller to avoid this issues in the future.
The location for this AutoYaST test suite should be similar than the rest of AutoYaST test suite for support in Yam squad, currently in: https://openqa.suse.de/group_overview/446
Step (2) will performed in #121912
Updated by JERiveraMoya about 2 years ago
- Related to action #121912: Create test suite to configure support server for SLE 15 SP4 added
Updated by syrianidou_sofia about 2 years ago
- Status changed from Workable to In Progress
- Assignee set to syrianidou_sofia
Updated by JERiveraMoya about 2 years ago
Hi @syarianidou_sofia, could we also cover here s390x kvm?
we would like to know if an AutoYaST job would resolve the problem with the repo here: https://openqa.suse.de/tests/10088581#downloads
because apparently when the product is already in maintenance and a specific build is not used should not give us any trouble.
Otherwise, we will need a ticket for s390x kvm.
Updated by JERiveraMoya about 2 years ago
- Related to action #120711: Move the "disable_installation_repos" ahead of registration for online migration cases added
Updated by syrianidou_sofia about 2 years ago
JERiveraMoya wrote:
Hi @syarianidou_sofia, could we also cover here s390x kvm?
we would like to know if an AutoYaST job would resolve the problem with the repo here: https://openqa.suse.de/tests/10088581#downloads
because apparently when the product is already in maintenance and a specific build is not used should not give us any trouble.
Otherwise, we will need a ticket for s390x kvm.
I will try to include s390x kvm. If it appears to be too much extra work, I will open a new ticket for it.
Updated by syrianidou_sofia about 2 years ago
- Status changed from In Progress to Feedback
https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/merge_requests/442
VRs passed:
s390x https://openqa.suse.de/tests/10232167 (not sure were the image is posted, logs show succesfull uploading)
x86_64 https://openqa.suse.de/tests/10230320
Updated by JERiveraMoya almost 2 years ago
- Status changed from Feedback to In Progress
syrianidou_sofia wrote:
https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/merge_requests/442
VRs passed:
s390x https://openqa.suse.de/tests/10232167 (not sure were the image is posted, logs show succesfull uploading)
x86_64 https://openqa.suse.de/tests/10230320
asset should be visible in the openQA job for s390x, normally PUBLISH_PFLASH_VARS should match the name with the publish variable, but we need to take a look.
Please do not use Feedback status, it is not required in our current workflow, it helps us to know that how much we collaborate internally.
Updated by syrianidou_sofia almost 2 years ago
removed the AUTOYAST selection and left the one specified in the schedule. New VRs:
64bit https://openqa.suse.de/tests/10297511
s390x https://openqa.suse.de/tests/10297512
PR: https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/merge_requests/442/diffs
Updated by JERiveraMoya almost 2 years ago
- Status changed from In Progress to Resolved