Migration from SLES12SP5 MU released to SLES15SP5 MU unreleased

[chcao]

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
• Verification run:
  https://openqa.suse.de/tests/14168907 (create support image by autoyast)
  https://openqa.suse.de/tests/14172378#step/zypper_lr/3 (migration job)
• Related mr: https://gitlab.suse.de/qe-yam/openqa-job-groups/-/merge_requests/139

[chcao]

Hi reviewers, please don't rush to merge it, just in case any troubles caused by them, but comments are welcomed, thanks.

[jknphy]

we don't need two test suites to do this, just single one.

[chcao]

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.

[jknphy]

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.

[chcao]

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.

[jknphy]

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.

[jknphy]

Additional information: https://suse.slack.com/archives/C02D1T4S58S/p1712927259849669

[chcao]

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.

[chcao]

Regarding the autoyast upgrade, I'll trace it in bug report bsc#1222432. So for this ticket, I'm using interactive migration.

[jknphy]

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?