coordination #152771
Updated by JERiveraMoya 3 months ago
#### Motivation
Follow-up of #113644
Due to we don't have technically the possibility to add both unreleased maintenance updates from both the origin product to migrate and the target product at the same time we can choose whatever fits better for us, one or the other. Based on this reasoning we should reuse the installations that we have for each product where we are already adding those unreleased maintenance updates to be tested in a way that we save patching time or troubles creating images to patch. We would just need to publish an image in existing test suites so the new migration test suite to be created will consume it. It is legit to create a dependency between installation and migration in maintenance updates testing due to priority of the migrations is secondary. Obviously using the unreleased maintenance updates for each job group representing each origin product will leave untested the latest product in maintenance (at the moment SLES 15 SP5) and migration which target it with unreleased maintenance updates. So only in this case we can do the migration in target, so we will pass the unreleased maintenance updates to the method o migration.
We should use an origin system provided by an autoYaST test suite in maintenance. We have some interactive installation and auto-installation, we should check that in our auto-installation we are maximizing the number of product modules installed, so the migration would be more effective. Do not link migration with interactive installation, create first the AutoYaST one if there is not there or edit the existing one. As we will not have initially more than one test suite to migration from one product to another we can discuss further what is the method of migration to be use, same for all might be ok to start, the most stable one if it is such a thing, or the less complex one from the code maintenance point of view.
There is some hacks with the flavors that we will need to improve, as we will work with the mediums that we have in maintenance updates, we will not create new flavors, so some of those existing hacks in product validation need to be addressed.
#### Scope
In respective job group indicated by "From".
- From SLES 12 SP5 To SLES 15 SP{1,4}.
- From SLES 15 SP1 To SLES 15 SP{2,4}.
- From SLES 15 SP2 To SLES 15 SP{3,4}.
- From SLES 15 SP3 To SLES 15 SP4.
In respective job group indicated by "To".
- From SLES 12 SP5 To SLES 15 SP5.
- From SLES 15 SP1 To SLES 15 SP5.
- From SLES 15 SP2 To SLES 15 SP5.
- From SLES 15 SP3 To SLES 15 SP5.
- From SLES 15 SP4 To SLES 15 SP5.
#### Acceptance criteria
**AC1**: Single test suites for migration is provided between the products above.
**AC2**: Unreleased maintenance updates are provided inside the image created by installation previously and published to be consumed (via START_AFTER_TEST) by the migration test suite for all maintenance product except SLES 15 SP5.
**AC3**: For SLE 15 SP5 we will add the unreleased maintenance updates during the migration procress itself, so the origin booted system only will be patched with released maintenance updates.
**AC4**: Favor stability using refactored test modules and existing libyui-rest-api test modules to enable this migration.
##### Additional information
Analysis by Heiko about the different possibilities:
https://confluence.suse.com/display/~hrommel1/Blue-Print+of+Online+Migration+Tests+Between+Two+Service+Packs+in+Maintenance
Names of migration test suites should start by `migr_*`.