QA » openQA Project » openQA Tests

Verified 7 profiles and filed bugs for following jobs, if we ignore known issues for some of them installation will work:
sles12_autoyast_bug-872532 - doesn't work
sles12_autoyast_bug-877438 - works
sles12_autoyast_bug-879147 - possible to complete installation
sles12_autoyast_bug-887126 - doesn't work
sles12_autoyast_bug-887653 - possible to complete installation
sles12_autoyast_mini - works
sles12sp2_autoyast_bug-876 - doesn't work

As next step we should introduce workaround for same 2 bugs which prevent system from installation:
https://bugzilla.suse.com/show_bug.cgi?id=1047327
https://bugzilla.suse.com/show_bug.cgi?id=1055034
So automated tests will show more issues, which expose current development stage.

@okurz I'm not sure if it's correct to reopen the ticket which is one month old. But at that point of time we've done everything we could. Now it's clear that all profiles have to be changed for sle 15, hence they will get new prefix. We also will need to create new test suites set or use some version magic. But fine with me, we can proceed with this ticket.

https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html documentation how to register system and select modules.

For SLE15 following changes have to be introduced in order to make sle12 specific profiles work:

1. Add <suse_register> section to register SUT to be able to add modules:

  <suse_register>
      <do_registration config:type="boolean">true</do_registration>
      <email></email>
      <reg_code>{{REG_CODE}}</reg_code>
      <install_updates config:type="boolean">true</install_updates>
      <reg_server>http://all-321.5.proxy.scc.suse.de</reg_server> <!-- Required for getting correct packages -->
  </suse_register>

1. Add <product>SLES15</product> under <software> for sles.

This brings a need to modify autoyast profiles before the installation in order to insert non-public data (e.g. reg code), and/or test scenario specific variable (e.g. architecture and version for module).

The solution which is preferable at the moment is to use one test suite which modifies the profiles and uploads them as assets and chained jobs use them for installation.
We will try to estimate implementation in api, so we could do that on the fly in single test suite, but solution mentioned about is already available and will work.

With the need to do the registration during installation and our hesitation to put the regcode into profiles into a public repo I wonder how customers see it because they basically have a similar problem then or would they use the all-packages-iso in such case to do the initial installation?

@okurz I believe common scenario will be to use registration data in the profile (or addons urls, as they are generated when cloning the system). I'll check if all packages iso can help here, as we still need to point to the media in some way.

Following 3 test suites use same autoyast profile:
autoyast+supportserver
gnome_http_autoyast
autoyast_gnome

Leaving only autoyast_gnome

For the profiles which are not blocked by bugs we've proposed a temporary solution which uses all packages DVD. See https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3865

Temporary solution for profiles here: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3865
Needs test suites settings adjustment. Once we have changes in openQA, we can modify profile in the runtime.

Better approach with runtime modification of profiles will be implemented in another ticket, please see https://progress.opensuse.org/issues/27505

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_lvm
https://openqa.suse.de/tests/1268995