action #11000
closedcoordination #15108: [sle][functional][u][epic] Modules (Installation + migration)
[Migration] migrations - upgrades with modules
100%
Description
we need migration scenarios to test upgrades still work when modules are present
at the very least we need sle12ga and sle12sp1 'all modules' upgrade test
This may depend on the SCC Proxy as modules are normally SCC dependant
For details about modules see
https://wiki.microfocus.net/index.php/Maintenance/SLE12_SP2_Online_Migration#Add-ons_and_modules_for_SLES
Unfortunately for certifications the wiki is not up-to-date: migration with certifications module is not possible (see bsc#980685 as well)
Files
Updated by dgutu over 8 years ago
- Related to action #10996: [sles][migration] fully patch before upgrading (offline+online) added
Updated by RBrownSUSE over 8 years ago
- Target version changed from Milestone 2 to 168
Updated by dgutu over 8 years ago
Migration with addons like HA and WE failed using SCC_Proxy.
Waiting for some updates from Artem from SCC team, other wise I will find a workaround :)
Updated by okurz over 8 years ago
- Target version changed from 168 to Milestone 3
Updated by okurz over 8 years ago
modules should be enabled now in scc proxy, can it work now? is there anything else blocking you?
You might need to ask Marita which module on which architecture are available in SCC. There should be documentation somewhere, Marita will provide link.
Updated by maritawerner about 8 years ago
Please start with Testcases that just install the modules on SLES, no add-ons at the beginning.
List of modules for the start:
*Advanced Systems Management Module 12
*Containers Module 12
*Toolchain Module 12
*Public Cloud Module 12
*Legacy Module 12
*Web and Scripting Module 12
Let's start with x86_64 and then add the Testcases to the other arches if applicable.
Updated by okurz about 8 years ago
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/1653 might help as I needed to change something in the registration code part already working on the salt stack which needs ASMM. dgutu, I recommend you look at my changes, register one module at a time and provide a PR when you have something working for one module, after that add more. After that add other arches, good suggestion by Marita.
Updated by dgutu about 8 years ago
okurz wrote:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/1653 might help as I needed to change something in the registration code part already working on the salt stack which needs ASMM. dgutu, I recommend you look at my changes, register one module at a time and provide a PR when you have something working for one module, after that add more. After that add other arches, good suggestion by Marita.
Thank you Oliver, good point.
I've took a look at your openQA instance I saw that you already testing the module for salt (Advanced Systems Management Module 12) and it works fine.
I've tried on my openQA to make use of all of the modules available and faced the issue about missing licence on 3 from 6.
I assume that we are missing some assets dirs in o.s.d so that proxy-scc can access needed files.
@Marita, whom to ask about this? Thx
Updated by okurz about 8 years ago
- Status changed from New to In Progress
Regarding the assets on o.s.d, yes, you are right. I guess https://gitlab.suse.de/openqa/scripts/blob/master/rsync.pl needs to be changed to sync modules, too. See #12908#note-4 for what rbrown, coolo and me discussed.
Updated by dgutu about 8 years ago
dgutu wrote:
okurz wrote:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/1653 might help as I needed to change something in the registration code part already working on the salt stack which needs ASMM. dgutu, I recommend you look at my changes, register one module at a time and provide a PR when you have something working for one module, after that add more. After that add other arches, good suggestion by Marita.
Thank you Oliver, good point.
I've took a look at your openQA instance I saw that you already testing the module for salt (Advanced Systems Management Module 12) and it works fine.I've tried on my openQA to make use of all of the modules available and faced the issue about missing licence on 3 from 6.
I assume that we are missing some assets dirs in o.s.d so that proxy-scc can access needed files.
@Marita, whom to ask about this? Thx
Because 'Live Patching' is more addon then module the issue I faces is about:
Legacy and Web Scriptin modules.
Updated by dgutu about 8 years ago
QA and personal SCC keys failing to be registered while I was trying to migrated HDD images
with all modules. Do you know when new key will be available, @marita?
Thx.
Updated by dgutu about 8 years ago
- % Done changed from 0 to 70
Today I have added 3 test-suites for allmodules migration.
The migration will run for now under the group - Test Development: SLE 12 SP3
Updated by maritawerner about 8 years ago
- Target version changed from Milestone 3 to Milestone 4
Updated by maritawerner almost 8 years ago
- Subject changed from migrations - upgrades with modules to (Migration] migrations - upgrades with modules
Updated by maritawerner almost 8 years ago
- Subject changed from (Migration] migrations - upgrades with modules to [Migration] migrations - upgrades with modules
Updated by okurz almost 8 years ago
- Has duplicate action #15570: [Migration] SLES: online migration with modules added
Updated by okurz almost 8 years ago
- Target version changed from Milestone 4 to Milestone 5
@dgutu please update this ticket with the current status and explanation of what blocked it from being completed within Milestone 4. I will try to support more on this task in the near future.
Updated by dgutu almost 8 years ago
I hope to get synced the modules repo URL to o.s.d by adapting rsync.pl but its the hardest way afaik.
Is there any alternative?
Modules require scc keys even if we will try to install them through proxy scc. Any updates on keys topic, Marita?
The doubt I hope is that the sync repo is the way customer will do it. IMO the real life example is to use
SCC + keys.
Please let me know your opinions on that. Thank you.
Updated by okurz almost 8 years ago
dgutu wrote:
I hope to get synced the modules repo URL to o.s.d by adapting rsync.pl but its the hardest way afaik.
Is there any alternative?
I only see the alternative of a post-release test, see below.
Modules require scc keys even if we will try to install them through proxy scc. Any updates on keys topic, Marita?
But modules are part of SLES and if you use a SLES key you have access to modules as well, e.g. see the keys on https://wiki.microfocus.net/index.php?title=YAST/reg_codes
what is the problem there?
The doubt I hope is that the sync repo is the way customer will do it. IMO the real life example is to use
SCC + keys.
Yes, you are right. But we want to ensure something different here: That the modules can be properly selected and installed, we don't want to test SCC here. A post-release test which relies on the modules being available over SCC is not a bad idea but if we see problems there then the customer can also see them and we want to ensure that modules are properly tested (at least installable) before release.
Updated by RBrownSUSE almost 8 years ago
Yes, you are right. But we want to ensure something different here: That the modules can be properly selected and installed, we don't want to test SCC here.
But the only supported way of selecting modules is THROUGH SCC (or it's API compliant cousins SMT and SUMA).. surely we therefore need to be testing SCC somewhat anyway?
Updated by dgutu almost 8 years ago
- % Done changed from 70 to 0
The reason I've asked for registration keys is because sles12SP3 has no modules available during registration using real SCC and the same is for Proxy_SCC. So even having sles12ga, sles12sp1 and sles12sp2 with all modules prepared the one way it to touch the monster rsync.pl, to be able to add them as separate repositories but IMO this is not the customer way.
Updated by okurz almost 8 years ago
RBrownSUSE wrote:
But the only supported way of selecting modules is THROUGH SCC (or it's API compliant cousins SMT and SUMA).. surely we therefore need to be testing SCC somewhat anyway?
yes, we test it implicitly. I wanted to express that testing SCC is not our only concern and probably less important than "modules can be installed" as I assume no one else is testing that but SCC itself is tested by SCC team from a system perspective already - a bit … I assume … I hope … I will ask artem tonight over an "agile beer" ;-).
dgutu wrote:
The reason I've asked for registration keys is because sles12SP3 has no modules available during registration using real SCC and the same is for Proxy_SCC.
yes, good observation. as discussed in jangouts today, maritawerner will ask about it.
touch the monster rsync.pl, to be able to add them as separate repositories but IMO this is not the customer way.
Lemme rephrase: Testing modules over real SCC is not the "validation" we want to ensure as the modules would only be available after the products are published, e.g. SLES 12 SP3 Beta1. We want to test our products, that is SLES+modules, before the customer is hit by bugs. Currently I do not know any better way than syncing them from IBS/dist to osd and using proxySCC. Additionally to that we can do "post-validation" tests, e.g. after the products milestone builds have been released to SCC we can verify the same as the customer would do.
Updated by maritawerner almost 8 years ago
Modules for SP3 are not enabled in SCC yet. I wait for Anja/Frederic to get back to us. They have to tell the SCC team when to enable them.
Updated by RBrownSUSE almost 8 years ago
Ok, but this ticket is obviously blocked until that is fixed
Updated by okurz almost 8 years ago
- Target version changed from Milestone 5 to Milestone 6
Updated by maritawerner almost 8 years ago
Artem promised to do it after Hackweek.
Updated by dgutu almost 8 years ago
maritawerner wrote:
Artem promised to do it after Hackweek.
Thx for this update.
Updated by dgutu almost 8 years ago
Modules are available, the only one is missing - Certifications but as per https://wiki.microfocus.net/index.php/Maintenance/SLE12_SP2_Online_Migration
this module will not be available for online migrations.
We already have hdd images prepared for migrations so its time to start working on this task.
Updated by dgutu almost 8 years ago
Some heads up on this task:
There are 3 jobs running for migrations and 1 for allmodules during installation of sles12sp3, all in test development group.
1 - Migrate of sles12ga-allmodules -> sles12sp3 is failing,installer wants to remove 4 modules from 6
https://openqa.suse.de/tests/807579#step/releasenotes/2
2 - Migrate sles12sp1-allmodules -> sles12sp3 is fine:
https://openqa.suse.de/tests/810747#step/releasenotes/2
3 - Migrate from sles12sp3-allmodules -> sles12sp3 is fine:
https://openqa.suse.de/tests/807581#step/releasenotes/2
I'll file a bug about first failing scenario.
Updated by dgutu almost 8 years ago
dgutu wrote:
Some heads up on this task:
There are 3 jobs running for migrations and 1 for allmodules during installation of sles12sp3, all in test development group.1 - Migrate of sles12ga-allmodules -> sles12sp3 is failing,installer wants to remove 4 modules from 6
https://openqa.suse.de/tests/807579#step/releasenotes/2
2 - Migrate sles12sp1-allmodules -> sles12sp3 is fine:
https://openqa.suse.de/tests/810747#step/releasenotes/2
3 - Migrate from sles12sp3-allmodules -> sles12sp3 is fine:
https://openqa.suse.de/tests/807581#step/releasenotes/2I'll file a bug about first failing scenario.
Updated by dgutu over 7 years ago
I've got the bug marked as invalid, you may take a look here:
https://bugzilla.suse.com/show_bug.cgi?id=1029170#c1
For me, it doesn't make sense at all - "Deactivate the modules before performing the migration itself"?
The hole sense of migration is about having everything installed and migration to the latest version or service pack, isn't ?
Please give some opinions.
P.S. - this doesn't happen on sp1 and sp2
Updated by maritawerner over 7 years ago
Dumitru, the difference is that sles12ga is not under general support anymore. customers have to buy LTSS (Long term service support) for sles12ga and there is no LTSS for modules. That means customers have to disable modules before the migration. For details see the PRD, 3.2.
BTW the Chinese colleagues have developed a support matrix that defines each separate migration Testcase. I attach an updated version.
Updated by dgutu over 7 years ago
- Status changed from In Progress to Feedback
- Assignee changed from dgutu to mitiao
I'd like to pass-over this task to Beijing team since they are responsible completely for migration.
I found that the testcases are already created but not yet assigned to any job group so its just a matter of time
since we are now able to install all modules through ProxySCC.
Wei Jang you can assign to someone accordingly.
Updated by okurz over 7 years ago
M6 is already long gone and M7 is also over.
@mitiao can you make sure the ticket is updated accordingly with the current status and necessary missing steps. Thank you.
Updated by mitiao over 7 years ago
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
We are running all migration tests with all modules in Milestone job groups.
The procedure looks fine. Set resolved, and if any related issue occur in future, we will raise new ticket to fix.