os-autoinst-distri-opensuse
os-autoinst-distri-opensuse copied to clipboard
os-autoinst
[WIP] Migration from SLES12SP5 MU released to SLES15SP5 MU unreleased
Add upragde autoyast profile and yaml schedule files for migration from mu released to mu unreleased testsuites.
- Related ticket: https://progress.opensuse.org/issues/154951
- Needles: n/a
- Verification run: https://openqa.suse.de/tests/13928295# (Job to register the image and publish image) https://openqa.suse.de/tests/13928917# (Job to do migration to SLES15SP5+MU_unreleased_updates)
- Related mr: https://gitlab.suse.de/qe-yam/openqa-job-groups/-/merge_requests/139
Hi reviewers, please don't rush to merge it, just in case any troubles caused by them, but comments are welcomed, thanks.
we don't need two test suites to do this, just single one.
I once tried to add just single one test suite, but it has a problem with setting SCC_ADDONS for the test suite. For details, please see the comment here: https://progress.opensuse.org/issues/154951#note-8 The Modules of SLES12SP5 and SLES15SPx are not the same: If we set SLES15SP5 modules in SCC_ADDONS setting, it would can not register them on SLES12SP5, for example base, serverapp, python3 etc. If we set SLES12SP5 modules in SCC_ADDONS setting, when it performing migration, the SLES15SP5's modules (e.g base, serverapp, python3 etc)' MU repos would not be added because they are not set in the SCC_ADOONS.
we don't need two test suites to do this, just single one.
I once tried to add just single one test suite, but it has a problem with setting SCC_ADDONS for the test suite. For details, please see the comment here: https://progress.opensuse.org/issues/154951#note-8 The Modules of SLES12SP5 and SLES15SPx are not the same: If we set SLES15SP5 modules in SCC_ADDONS setting, it would can not register them on SLES12SP5, for example base, serverapp, python3 etc. If we set SLES12SP5 modules in SCC_ADDONS setting, when it performing migration, the SLES15SP5's modules (e.g base, serverapp, python3 etc)' MU repos would not be added because they are not set in the SCC_ADOONS.
that can be done setting SCC_ADDONS during the test to the right value based on another variable, for instance SCC_ADDONS_ORIGIN or SCC_ADDONS_TARGET. That is much more simple than maintain another job running publishing and booting unnecessarily.
This is the latest VR for this PR, the wired thing is that the MU repos can not be seen after migration still: https://openqa.suse.de/tests/14014974#step/zypper_lr/3 (I also checked the la /etc/zypp/repos.d manually, no MU repos found there) But in a previous jobs, I could see MU repos in this screenshot: https://openqa.suse.de/tests/13993685#step/installation/5 (using the same autoyast profile) So I think the repos are missing during installation. I will save y2log and send to yast developers to take a look at it next Monday, because they prefer y2logs with Y2DEBUG disabled.
This is the latest VR for this PR, the wired thing is that the MU repos can not be seen after migration still: https://openqa.suse.de/tests/14014974#step/zypper_lr/3 (I also checked the la /etc/zypp/repos.d manually, no MU repos found there) But in a previous jobs, I could see MU repos in this screenshot: https://openqa.suse.de/tests/13993685#step/installation/5 (using the same autoyast profile) So I think the repos are missing during installation. I will save y2log and send to yast developers to take a look at it next Monday, because they prefer y2logs with Y2DEBUG disabled.
there is different syntax among major versions which is quite suspicious... https://suse.slack.com/archives/C02CLB2LB7Z/p1712922267535649?thread_ts=1712918411.656059&cid=C02CLB2LB7Z
I noticed we should not add the updates of the target product to the origin product: https://openqa.suse.de/tests/13993685#step/patch_sle/195 that might cause some troubles.
Additional information: https://suse.slack.com/archives/C02D1T4S58S/p1712927259849669
This is the latest VR for this PR, the wired thing is that the MU repos can not be seen after migration still: https://openqa.suse.de/tests/14014974#step/zypper_lr/3 (I also checked the la /etc/zypp/repos.d manually, no MU repos found there) But in a previous jobs, I could see MU repos in this screenshot: https://openqa.suse.de/tests/13993685#step/installation/5 (using the same autoyast profile) So I think the repos are missing during installation. I will save y2log and send to yast developers to take a look at it next Monday, because they prefer y2logs with Y2DEBUG disabled.
there is different syntax among major versions which is quite suspicious... https://suse.slack.com/archives/C02CLB2LB7Z/p1712922267535649?thread_ts=1712918411.656059&cid=C02CLB2LB7Z
I tried with only <media_url><%= $repo %></media_url> way (no repo name) and with <add_on_others config:type="list">, it doesn't work: https://openqa.suse.de/tests/14028159#step/zypper_lr/3
Let me have a try with <addon_on_products>, Sofia's case work with it, I'll have a try.
I noticed we should not add the updates of the target product to the origin product: https://openqa.suse.de/tests/13993685#step/patch_sle/195 that might cause some troubles.
Yes, you are right, the mu repos are adding in SLES12SP5, I post a wrong link here. This is the correct one: https://openqa.suse.de/tests/13973330#step/installation/6
Additional information: https://suse.slack.com/archives/C02D1T4S58S/p1712927259849669
I'll try <addon_on_products> + <media_url><%= $repo %></media_url> , if it still won't work, I'll switch back to use interactive migration for this ticket, and trace the AutoYaST upgrade issue with the bug again.
Regarding the autoyast upgrade, I'll trace it in bug report bsc#1222432. So for this ticket, I'm using interactive migration.
Regarding the autoyast upgrade, I'll trace it in bug report bsc#1222432. So for this ticket, I'm using interactive migration.
Regarding the autoyast upgrade, I'll trace it in bug report bsc#1222432. So for this ticket, I'm using interactive migration.
We cannot merge interactive migration without using libyui-rest-api (and that would be a lot of work) but yeah code with needles in SLES SP5 is a no-go. Is there any "cheap" way to have the migration with other method via command line?