QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

Motivation¶

In our current SLEM migration testings, we add original product's MU patch, then fully update the packages to install these patches, and then perform online migration, that is original product + MU -> target product migration.

While it happens that both original product and target product have its MU patch. In this situation, the package's version (from the MU patch) would be higher then target product's package version, because we do original product + MU -> target product migration now, it may cause some issues, for example [this failure] which is caused by the target product's (slem 5.3) wicked package is also in MU testing and not added in this testing.

So this ticket is to resolve these issues by bring both MU patches, the way is to add new settings, like "TARGET_OS_TEST_ISSUES" and "TARGET_OS_TEST_REPOS" to list the target product's MU patches and patches links in the settings (BTW, these settings will not be automatically triggered I think, when these kind of issues happen in the testing, we may need to retrigger the jobs + these settings). And adapt the openqa automation code to add the patches from TARGET_OS_TEST_REPOS parameters by zypper ar -f (reference the code of "add_test_repositories") at the beginning of test module "zypper_migration" for SLEM only.
Then the SLEM migration cases would be original product + MU -> target product + MU.

Acceptance criteria¶

• AC1 : Implement automation to add SLEM migration target product's MU patch before migration via settings
• AC2 : The mechanism implemented should serve just a way to debug problems for cases like that mentioned above.

Suggestions¶

As this ticket is to implement a debug mechanism, perhaps the setting should start by DEBUG_ or similar.