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

Motivation¶

It should be more clear just looking at the test module what are the actions in drop_unavailable_product_modules.pm

Of course, we are talking about the function sub deregister_dropped_modules to extract its logic in different test modules, the code is just iterating over comma-separated values in settings, creating unnecessary complexity. We need test modules which address specific actions in a very straightforward way and very transparent display, so any user (ie: a developer in a bug report) could reproduce manually this. This piece of code seems to be doing:
This block deals with LTSS, it should have its own test module with name (according to documentation disable_ltss.pm (let's use some hash instead of if/else conditions here)

remove_suseconnect_product('SLE_HPC-LTSS');
remove_suseconnect_product('SLES-LTSS');

Do we really use or need this part in the YaM scope?

zypper_call 'rm -t product SLES-LTSS';
zypper_call 'rm sles-ltss-release-POOL';

We don't need setting DROPPED_MODULES because the only other case to be taking into account is the python2 so let's create a test module only for this

remove_suseconnect_product(get_addon_fullname($name));

Finally after each the two modules create above we might need to adjust the settings, but I don't think it is responsibility of this module to do this, during the migration itself ltss or python can be excluded. File a ticket to adjust it there if it is not possible at the moment and keep this code or even better fix it there on target.

@all_addons = grep { $_ ne $name } @all_addons;
set_var('SCC_ADDONS', join(',', @all_addons));

Acceptance criteria¶

AC1: Split/improve this piece of logic following recommendations above

Additional information¶

Refactored test suite are currently in this job group with names ending on *_split_patch_sle.