Project

General

Profile

Actions

action #11000

closed

coordination #15108: [sle][functional][u][epic] Modules (Installation + migration)

[Migration] migrations - upgrades with modules

Added by RBrownSUSE almost 9 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
New test
Start date:
2016-02-29
Due date:
% Done:

100%

Estimated time:
Difficulty:

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


Checklist

  • sle

Related issues 2 (0 open2 closed)

Related to openQA Tests (public) - action #10996: [sles][migration] fully patch before upgrading (offline+online)Resolvedmitiao2016-02-29

Actions
Has duplicate openQA Tests (public) - action #15570: [Migration] SLES: online migration with modulesRejectedmitiao2016-12-20

Actions
Actions #1

Updated by dgutu almost 9 years ago

  • Assignee set to dgutu
Actions #2

Updated by dgutu over 8 years ago

  • Related to action #10996: [sles][migration] fully patch before upgrading (offline+online) added
Actions #3

Updated by RBrownSUSE over 8 years ago

  • Target version changed from Milestone 2 to 168
Actions #4

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 :)

Actions #5

Updated by okurz over 8 years ago

  • Target version changed from 168 to Milestone 3
Actions #6

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.

Actions #7

Updated by maritawerner over 8 years ago

  • Description updated (diff)
Actions #8

Updated by dgutu over 8 years ago

Add-ons: SDK, WE, HA, HAGeo, Live_Patching

Actions #9

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.

Actions #10

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.

Actions #11

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

Actions #12

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.

Actions #13

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.

Actions #14

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.

Actions #15

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

Actions #16

Updated by maritawerner about 8 years ago

  • Target version changed from Milestone 3 to Milestone 4
Actions #17

Updated by maritawerner almost 8 years ago

  • Subject changed from migrations - upgrades with modules to (Migration] migrations - upgrades with modules
Actions #18

Updated by maritawerner almost 8 years ago

  • Subject changed from (Migration] migrations - upgrades with modules to [Migration] migrations - upgrades with modules
Actions #19

Updated by okurz almost 8 years ago

  • Has duplicate action #15570: [Migration] SLES: online migration with modules added
Actions #20

Updated by okurz almost 8 years ago

@dgutu: Please consult with @mitiao who opened #15570

Actions #21

Updated by okurz almost 8 years ago

  • Parent task set to #15108
Actions #22

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.

Actions #23

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.

Actions #24

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.

Actions #25

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?

Actions #26

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.

Actions #27

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.

Actions #28

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.

Actions #29

Updated by RBrownSUSE almost 8 years ago

Ok, but this ticket is obviously blocked until that is fixed

Actions #30

Updated by okurz almost 8 years ago

  • Target version changed from Milestone 5 to Milestone 6
Actions #31

Updated by maritawerner almost 8 years ago

Artem promised to do it after Hackweek.

Actions #32

Updated by dgutu almost 8 years ago

maritawerner wrote:

Artem promised to do it after Hackweek.

Thx for this update.

Actions #33

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.

Actions #34

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.

Actions #35

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/2

I'll file a bug about first failing scenario.

https://bugzilla.suse.com/show_bug.cgi?id=1029170

Actions #36

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

Actions #37

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.

Actions #38

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.

Actions #39

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.

Actions #40

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.

Actions

Also available in: Atom PDF