action #12908
closedcoordination #15108: [sle][functional][u][epic] Modules (Installation + migration)
Feature 318875 and 320919: Add Saltstack to the Advanced Systems Management Module
0%
Updated by okurz over 8 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).
Updated by RBrownSUSE over 8 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 :)
Updated by okurz over 8 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
Updated by dgutu about 8 years ago
Please consider also to add to rsync.pl also two modules: "Legacy Module 12" and "Web and Scripting Module 12"
I need this for the https://progress.opensuse.org/issues/11000
Thx.
Updated by okurz about 8 years ago
As long as
ssh login "ls /mounts/dist/ibs/SUSE/Products/SLE-Module-Adv-Systems-Management/12/x86_64/product/x86_64/" | grep salt
does not return any salt packages I assume the feature is not yet done.
Updated by okurz about 8 years ago
- Assignee deleted (
okurz)
There is nothing I can do right now. salt is missing from product.
Updated by maritawerner about 8 years ago
- Priority changed from High to Normal
- Target version deleted (
Milestone 3)
Updated by maritawerner almost 8 years ago
- Status changed from Feedback to Resolved
Feature now implemented, QAM has tested it according to the Fate comments.
Updated by okurz almost 8 years ago
- Status changed from Resolved to Feedback
wait, we still don't have an automated test for that so we should track and plan for it, correct? So should we plan it for SLE12SP3 then?
Updated by maritawerner almost 8 years ago
- Status changed from Feedback to Resolved
Well, the feature itselt is done and we do not test the module itself. We just make sure that it is installable.
Updated by okurz almost 8 years ago
maritawerner wrote:
We just make sure that it is installable.
that is the part I doubt because I don't know of any automatic test that tests the installation of the module.
Updated by maritawerner almost 8 years ago
Agredd that is still missing and tracked in ticket https://progress.opensuse.org/issues/15108
But I agree that the tickets around modules/migration need some clean up.
Updated by dgutu over 7 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/