[sle][migration] Bsc#1086818 Migration: new modules not correctly added
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
#4 Updated by maritawerner over 3 years ago
Additional email from Thorsten Kukuk:
On Mon, Apr 09, Yan Sun wrote:
- 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.
This is not easy fixable and a fix will come very late.
Additional, SCC handles free extensions like modules:
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
SLES12 SP3 maps to:
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.
#5 Updated by maritawerner over 3 years ago
Yet another email thread between Sunny and Thorsten:
On Thu, Apr 12, Yan Sun wrote:
On 04/09/2018 07:23 PM, Thorsten Kukuk wrote:
- 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
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.
- 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.
- 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?
- 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.
#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?
#10 Updated by okurz over 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
- 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