QA (public) » openQA Project (public) » openQA Tests (public)

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

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.

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

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.

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.

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

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.

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.

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

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.

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.

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?

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.

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.

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

Artem promised to do it after Hackweek.

maritawerner wrote:

Artem promised to do it after Hackweek.

Thx for this update.

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.

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.

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

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

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.