action #15108: [sle][functional][u][epic] Modules (Installation + migration)
Feature 318875 and 320919: Add Saltstack to the Advanced Systems Management Module
#1 Updated by okurz over 3 years ago
- Status changed from New to Feedback
- Assignee set to RBrownSUSE
backlink added to both fate entries. Why should we test this in openQA, though?
AFAIU it's merely checking if a module is available as part of a model.
Why automate? Can we not just check once in a package list on IBS it's there? Unless we are talking about running salt, that's a different story. As we added a simple "ping" test to openQA and run it as part of openSUSE we can also add it to SLE (it's more complicated though because of relying on the module).
#2 Updated by RBrownSUSE over 3 years ago
- Status changed from Feedback to New
- Assignee changed from RBrownSUSE to okurz
checking the packagelist doesn't ensure that the package is installable
Minimum criteria for this progress item is
- Install ASM Module
- Ensure Salt can be installed
Bonus criteria is to actually test salt, but we have tests for that now, so, lets add them too :)
#4 Updated by okurz over 3 years ago
Current state: Feature test: FAILED
Local verification: http://lord.arch/tests/2618#step/install_and_reboot/21
/mounts/dist/ibs/SUSE/Products/SLE-Module-Adv-Systems-Management/12/x86_64/product/x86_64/ does not include any salt packages so far. bsc#989693 needs to be resolved before the test could pass.
Remarks for the test implementation:
sync module in rsync.pl
set SCC_ADDONS=asmm (as salt should be in asmm module)
During scc_registration the addon should be enabled
<okurz> SLE addon question: If I select a module during installation, should this selection be visible in installation_summary? http://lord.arch/tests/2618 <coolo> okurz: installation overview only shows products, i.e. addons <rbrown> okurz, looks like you picked the asmm module, but no asmm packages <okurz> I enabled http://lord.arch/tests/2618#step/scc_registration/10 but did not select any additional software to install but just expect zypper search to find salt later <okurz> ok, so "zypper search salt" should find something and "zypper lr" should list something additional to just the SLES repo? <rbrown> yes <okurz> yes, that's fine. Previously I already conducted this test but no module channels showed up in the installed system. I guess the module installation during scc_registration was never done besides textmode during online migration <okurz> oh no, I need the assets on openqa.suse.de first, it seems. why does online migration work then? <okurz> coolo, rbrown: Am I right to assume that https://openqa.suse.de/tests/498069#step/register_system/68 shows only that all modules have been registered in this online migration scenario but are not available because we don't sync them to openqa? Should I then change rsync.pl to also sync the module asmm to openqa and waste more space for my test to work? <coolo> okurz: every module to test we have to sync and specify the build number in scc proxy url <coolo> rbrown: the problem is that as soon as we use proxy scc, proxy scc rewrites every URL given to be openqa.suse.de - including modules <okurz> but as http://lord.arch/tests/2618#live shows it is not giving us the URL with the real BUILD included but just like "POOL-x86_64-Build-Media1" <okurz> Should I sync the ASMM module *for every build* or register against real SCC (which regcode code?) <rbrown> Modules change on a totally different pace to products..I don't think we need to sync for every build, but we need it to be there for the use of every build <coolo> okurz: we need something like the latest_addon function in rsync.pl - and then sync like every morning the modules from a different script <coolo> or do the sync on demand but have rsync.pl reference the latest there is <rbrown> +1 what coolo just said
#16 Updated by dgutu almost 3 years ago
I found the salt living here - http://dist.suse.de/ibs/SUSE/Updates/SLE-Module-Adv-Systems-Management/12/x86_64/update/x86_64/