action #113647
closedcoordination #113644: [Epic] Add migration paths with unreleased maintenance updates
Setup in development group an offline migration SLE-15-SP3->SLE-15-SP4 with SLE-15-SP3 unreleased MUs
Description
Motivation¶
Based on research in #113650 we should be able to upgrade SLE-15-SP3 containing latest maintenance updates to SLE-15-SP4 (SCC without MUs)
In this ticket we will kick off the upgrade process for Maintenance updates. The simplest path is to migrate between 2 versions of the product in maintenance that are closed to each other, in this case SLE-15-SP3 and SLE-15-SP4. We will start from the path which go from unofficial channels to official ones.
We will be using some minimal system, we have available for SLE-15-SP3 image already patched with maintenance updates created by this job: create_hdd_yast_maintenance_minimal
As the research shows, there was some issues with this image, YaST migration detects that there are not product installed, check research ticket for more info. So in case this problem is not solved we can use mru-install-minimal-with-addons which works just fine.
Acceptance criteria¶
AC1: New test suite where we proceed with migration is added to SLE-15-SP3 in YaST MUs - Development
AC2: This test suite is chained with existing attended or unattended (pick the one that works) installation.
AC3: Interaction with yast2 migration are done using libyui (let's keep it simple for now)
Suggestions¶
Instead of implementing layers of testing for libyui REST Test -> Controller -> Page, let's simplify development and declare Pages at the level of test, the page will have the UI controls mapped as usual, but there is not need for controller or to use a Distribution pattern. Later on we can think if we need for some cases that complexity. (let's keep it simple for now)
We can skip additional checks and decide in other ticket what exactly we want to add. For example we see here in this example pre_migration, etc.
https://openqa.suse.de/tests/8753537 Let's do the basic here only.
Here we can see how the YaST module perform the migration using SLE-15-SP3 (not SLE-15-SP4 as initially we thought, so the AutoYaST job should work, see bsc#1201698
During the ticket development it was decided to go for the offline migration as we can change the ISO. This one is the one expected to be delivered.
Updated by JERiveraMoya almost 2 years ago
- Tags set to qe-yast-refinement
- Target version set to Current
Updated by JERiveraMoya almost 2 years ago
- Subject changed from Upgrade from SLE-15-SP3 with maintenance updates to SLE-15-SP4 GM to Automate upgrade from SLE-15-SP3 with MUs to SLE-15-SP4 GM
Updated by JERiveraMoya almost 2 years ago
- Tags changed from qe-yast-refinement to YaST
- Priority changed from Low to Normal
Updated by JERiveraMoya almost 2 years ago
- Tags changed from YaST to qe-yast-refinement
- Description updated (diff)
- Priority changed from Low to Normal
Updated by JERiveraMoya almost 2 years ago
- Tags deleted (
qe-yast-refinement) - Status changed from New to Workable
Updated by JERiveraMoya almost 2 years ago
- Status changed from Workable to In Progress
Updated by JRivrain almost 2 years ago
Note: there are two types of migration with yast, one where we choose "upgrade" (eg autoupgrade_sles15sp3_scc_basesys-srv_all_full_auto ) in the bootloader, and one with the yast module in the installed system, the zypper way being out of scope for us.
As of now, it looks simpler to implement a test suite that does the "autoupgrade", as it seems to work out-of-the box with the image from create_hdd_maintenance_desktop: http://waaa-amazing.suse.cz/tests/17297.
But we probably want both.
Updated by coolgw over 1 year ago
Use following qcow as 15sp3 base qcow with latest unofficial patch(MU patch) and create another chain job for migration(using yast migration command)
https://openqa.suse.de/tests/9157239/asset/hdd/SLES-15-SP3-x86_64-mru-install-minimal-with-addons-Build20220717-1-Server-DVD-Updates-64bit.qcow2
That's what i understanding for this ticket.
Updated by JRivrain over 1 year ago
coolgw wrote:
Use following qcow as 15sp3 base qcow with latest unofficial patch(MU patch) and create another chain job for migration(using yast migration command)
https://openqa.suse.de/tests/9157239/asset/hdd/SLES-15-SP3-x86_64-mru-install-minimal-with-addons-Build20220717-1-Server-DVD-Updates-64bit.qcow2That's what i understanding for this ticket.
I also understand it this way, the question I wonder is if we should use autoyast, the yast module, or both, to perform the upgrade. The autoyast way looks much easier, but this ticket covers the yast module. One more way would be interactive upgrade from the installer.
Updated by JRivrain over 1 year ago
Updated by JRivrain over 1 year ago
I did more research for this ticket, as the parent ticket was blocked by some likely sporadic or un-reproducible bug.
This yast2-migration module is quite complex and requires some loops in order to solve random package conflicts that will inevitably occur as each MU build is different from the previous one. The legacy code for handling those conflicts looks broken but could serve as a base.
Then, I've been trying to figure out how to not use distribution pattern and controller, for now I'd rather keep it as we deal with many products in MU and migration, unless we want to end-up with a lot of different modules for each product or conditions in the code (no way). Maybe we can do something with the new scheduling capacities that @JERiveraMoya developed, but then it my be just moving the complexity elsewhere I think, I could give it a try to see if it really simplifies our life, or not.
Updated by JRivrain over 1 year ago
If we use the autoyast job as parent, we have the problem described in https://bugzilla.suse.com/show_bug.cgi?id=1201984. It is due to the -release files not being installed with autoyast, however they are installed in interactive installation. After some unsuccessful research I asked a question about this in help-yast channel, we'll see if they know some autoyast parameter that would fix it. Otherwise the following hack can be used after installation, for each activated add-on, install the release file (-y =yes, -l to accept licenses)
for i in `SUSEConnect --list-extensions |grep Deactivate |awk '{print $6}' |cut -d/ -f 1`; do zypper in -yl $i-release ; done
Updated by JRivrain over 1 year ago
The missing release files is a bug, reported: https://bugzilla.suse.com/show_bug.cgi?id=1202234
Meanwhile, we can either work-around it or use interactive installation from core maintenance as parent job.
Updated by JERiveraMoya over 1 year ago
- Subject changed from Automate upgrade from SLE-15-SP3 with MUs to SLE-15-SP4 GM to Setup in development group an offline migration SLE-15-SP3->SLE-15-SP4 with SLE-15-SP3 unreleased MUs
- Description updated (diff)
Updated by JERiveraMoya over 1 year ago
Updated by JRivrain over 1 year ago
MR https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/merge_requests/364
PR https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15469
VRs
using autoupgrade_sles15sp3_scc_basesys-srv_all_full_auto as base, with HDD_1 from create_hdd_yast_maintenance_desktop, it works: http://waaa-amazing.suse.cz/tests/17805
from job post: https://openqa.suse.de/tests/9440657 with post job fails because main*pm (or something else) modifies the variables, but otherwise should work once yaml schedule is merged.
Updated by JRivrain over 1 year ago
Additionally I publish a draft PR with some experiments I did, some of it could be useful
Updated by JERiveraMoya over 1 year ago
- Related to action #116578: Ensure image deregistered & MU repos cleaned before migration SPn->SPn+1 from SPn added
Updated by JERiveraMoya over 1 year ago
I added here #116581 so we can save some time when doing the online one. thanks!
Updated by JERiveraMoya over 1 year ago
- Status changed from In Progress to Resolved