Project

General

Profile

action #34411

[sle][migration] Bsc#1086818 Migration: new modules not correctly added

Added by maritawerner over 3 years ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
New test
Target version:
-
Start date:
2018-04-27
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:

Description

bsc#1086818 Migration: new modules not correctly added
is a shipstopper that is not covered in our testcases yet. Once fixed we need to test it.

Testing instructions from Thorsten Kukuk:

Could you please provide us a few Testcases that can be performed to make
sure that migration works and the bug is fixed?

The test case is the initial comment from me. You need to make sure, that
all added Modules are installed and registered.

Is it a valid Testcase to test with SUSEConnect the list of available
Modules and check if all expected modules are correctly registered? And what
is the correct list of expected modules for what scenario?

The list of expected modules is a moving target, hard coding
anything doesn't help here.
As I did show you: you need to show which Modules are there,
if the -release.rpm from this Module is installed and if this
Module is registered.
See bsc#1086846 *-release.rpm not installed for modules added via add_on_products.xml


Subtasks

action #35631: [sle][functional][u] Check that SLE modules are correctly registered after installation with SUSEConnectRejectedokurz


Related issues

Related to openQA Tests - action #34069: [sle][migration][sle15] Update snapper_rollback test module to check registration statusResolved2018-03-30

History

#1 Updated by maritawerner over 3 years ago

  • Subject changed from [sles][migration][functional] Bsc#1086818 Migration: new modules not correctly added to [sle][migration][functional] Bsc#1086818 Migration: new modules not correctly added

#2 Updated by maritawerner over 3 years ago

  • Project changed from SUSE QA to openQA Tests
  • Target version changed from Milestone 16 to Milestone 16

#3 Updated by okurz over 3 years ago

  • Related to action #34069: [sle][migration][sle15] Update snapper_rollback test module to check registration status added

#4 Updated by maritawerner over 3 years ago

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

#5 Updated by maritawerner over 3 years ago

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

#7 Updated by okurz over 3 years ago

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?

#8 Updated by okurz over 3 years ago

  • Category set to New test

#10 Updated by okurz about 3 years ago

  • Subject changed from [sle][migration][functional] Bsc#1086818 Migration: new modules not correctly added to [sle][migration] Bsc#1086818 Migration: new modules not correctly added

thx for the answer. I will remove the [functional] tag now as it applies only to the subtask then

#11 Updated by okurz almost 3 years ago

  • Target version deleted (Milestone 16)

M16 is closed for long time already.

#12 Updated by leli about 1 month ago

  • Assignee set to leli

#13 Updated by leli about 1 month ago

  • Status changed from New to Resolved

This issue should already been fixed.
See the test results of migration from SLES12SP5 to SLES15SP3, https://openqa.nue.suse.com/tests/5991105#step/installation_overview/1

Also available in: Atom PDF