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

Additional email from Thorsten Kukuk:

Hi,

On Mon, Apr 09, Yan Sun wrote:

1. We got SLE15 Migration slides from Sebastian on Mar 26th, which was composed by Thorsten, and from that moment, it seems the design of module mapping was clear.

Yes and No.
The problem is: when we discussed in R&D the Module setup, we only
looked at the modules coming from the SLE department, we had no insight
into modules from other groups.

Unfortunatley, this did lead to a SCC implementation, which always enables
all modules, which is not what our initial goal was.
=> https://bugzilla.suse.com/show_bug.cgi?id=1081543

This is not easy fixable and a fix will come very late.

Additional, SCC handles free extensions like modules:
=> https://bugzilla.suse.com/show_bug.cgi?id=1088480

This is of course not what we wanted, too. But it looks like we can
fix this bug quickly.

I list the background as example here, because some migration designs
are decided and clarified in our bug reports or mail interaction, which
is quite challenge for us.

Not only for you.

@ Thorsten, we compose module mapping list as attachment to confirm
the design, please let me know if you have different view. Thank you
for doing migration testing!

The mapping is not really that way.

Correct (but currently not possible, see above), would
be:

SLES12 SP3 maps to:

• SLE-Product-SLES15
• SLE-Module-Basesystem15
• SLE-Module-Desktop-Applications15
• SLE-Module-Legacy15
• SLE-Module-Server-Applications15
• SLE-Module-Web-Scripting15

Adv. Sys. Mgmt -> was dropped
(But since Adv. Sys. Mgmt required SLES12 SP3, you will get above list).

Containers -> SLE-Module-Containers15

Web & Scripting -> [list of SLES12 SP3]

Toolchain -> [list of SLES12 SP3] + SLE-Module-Containers15 + SLE-Module-development-tools15

Legacy -> SLE-Module-Legacy15

Certification -> not ready

Public Cloud -> SLE-Module-Public-Cloud15

HPC -> I don't know

SDK -> See Toolchain

Package Hub -> SUSE-Package-Hub15 (Extension, not Module!)

This is the minimal list of modules or extensions, to which
a product or module should be migrated. Since e.g. the Container
Module also requires a base system, a SLES12 SP3 with Container
Module will migrate to the above below SLES12 SP3 modules plus
the Container Module.
Due to the two above mentioned bugs, you will currently see even much
more modules. I hope that we get this right for SLE15 SP1.

Thorsten

Yet another email thread between Sunny and Thorsten:

Hi,

On Thu, Apr 12, Yan Sun wrote:

On 04/09/2018 07:23 PM, Thorsten Kukuk wrote:

1. The [list of SLES12 SP3] was named as "Blessed modules list" in the attachment, so if you see "Blessed modules list" + "SLE-Module-Containers15" in one space, which means

• SLE-Product-SLES15
• SLE-Module-Basesystem15
• SLE-Module-Desktop-Applications15
• SLE-Module-Legacy15
• SLE-Module-Server-Applications15
• SLE-Module-Web-Scripting15
• SLE-Module-Containers15

My first question is why SLE-Module-Containers15 is expected when we
include Toolchain or SDK on SLE12 SP3?

The Toolchain Module requires all other modules, but we cannot
express this with dependencies
I expect this only working correct with SLE15 SP1 earliest.

1. I am not fully understand the last sentence "I hope that we get this right for SLE15 SP1." Does it mean attached mapping list is a wish list for SLE15 SP1 (if so, we are not sure the expected result for SLE15 now, then we don't know if we should file bug for module relevant testing)?

I mentioned the two bugs which blocks a correct mapping currently.
So you can get more modules registered during upgrade than you need.

1. With below changed for Adv. Sys. Mgmt, Toolchain and SDK, we can expect all registration information about them on SLE15 should be dropped, shouldn't it?

Yes.

1. Do we expect IBM module (the 3rd party module) ready for testing before GM? If not, we will not test it even though it is available on SLE12 SP3.

I have no idea about the IBM modules.

Thorsten

subtask created for a check in the installed system for properly registered modules. I scheduled this for M19 so not within M16 as for functional I see no critical problem based on our existing automated and manual tests hence the lower priority. For migration the issue is more pressing but I think there has been some progress.

@sunyan can you give us a bit better overview what has been automated so far for checking that modules are registered after migration? I think I have seen already test code for that?