QA (public) » openQA Project (public) » openQA Tests (public)

Something like openqa_clone_job_osd --skip-chained-deps 1765305 SCC_ADDONS=pcm _GROUP="Test Development: SLE 12 SP4" TEST=allmodules+allpatterns+scc INSTALLONLY= could be used to trigger an installation enabling the PCM and installing according patterns. Then later on the specific test plan needs to be adjusted, e.g. it does not make sense to trigger console/yast2_bootloader on a cloud instance.

$ PERL5LIB= openqa-clone-job --skip-download --from https://openqa.suse.de --host https://openqa.suse.de --skip-chained-deps 1765305 SCC_ADDONS=pcm _GROUP="Test Development: SLE 12 SP4" TEST=pcm+allpatterns+scc INSTALLONLY= SCC_REGISTER=installation EXCLUDE_MODULES=yast2_bootloader
Created job #1765883: sle-12-SP4-Server-DVD-x86_64-Build0256-allmodules+allpatterns@64bit -> https://openqa.suse.de/t1765883

https://openqa.suse.de/t1765883

okurz wrote:

We will see what we can do within the next sprint. My hope is that with Clemens' (cfconrad) knowledge we could save a lot of time what scenarios in particular make sense.

Do I get the question right, that you asking what packages or even patterns can be installed at the same time and which not regardless the public cloud provider?
For example, to install aws-cli beside the google-cloud-sdk.

Whatever makes most sense from the customer point of view. Our tests should not reflect what is technically possible but what is useful. So it could mean that we want to have a test that installs aws-cli in parallel to google-cloud-sdk, it could also mean that we need multiple scenarios for each cloud provider and only install a subset of patterns in each, e.g.

• google

  • pattern1
  • pattern2+3

• aws

  • pattern4
  • pattern5
  • pattern6

• azure

  • pattern7+8+9

In the meantime I asked Public cloud team to get some help and suggestions, so the AC1 could be met. I found them more than useful in such situation. They are really willing to help and they always provide me with professional support.

I kept all interested parties in that email thread.

I hope this model of cooperation is OK for Public Cloud team, as Marita expressed some worries that the whole communication flow might be cumbersome for them. I share this worry, so let us hope this won't be the case. But if this risk will materialize, we would need to adapt somewhat.

Basically I asked them if they could help us specifying "test scenarios for each public cloud provider" while "enabling PCM during installation and selecting the corresponding patterns in each scenario".

"Would it be possible for you to help the team (QA SLE Functional) to have specific test scenarios for each public cloud provider in so-called "offline" mode please?"

answer provided by Robert Schweikert via email:

"Sure this is reasonably straight forward.

*-Services-Instance-Init

• Packages from these patterns should only be install tested. NO services from packages in these patterns should be enabled and the system be rebooted or the services started. It is possible to enable the services provided by these packages and check that the proper symlinks are created, but the "offline" test system should never be rebooted or the services explicitly started.

*-Services-Instance-Tools and *-Services-Tools

• All packages should be installable, packages are not expected to provide any services, and all code is expected to work on any system.

*-All

• A collection of all other patterns, thus conditions listed above apply."

See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html