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

The scenario is called minimal+base+sdk+proxy_SCC-postreg, belonging to job group Functional: Server.
Here is an example testrun: https://openqa.suse.de/tests/1058256

For SLE15 it already exists: https://openqa.suse.de/tests/1119787

Local testrun: f146.suse.de/tests/1016

please update tickets "In Progress" at latest EOB (end of business day) with either having it resolved - of course preferred ;-) - or with a clear comment why it was not finishable within the day.

PR created. https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3475

see https://openqa.suse.de/tests/1173434
and https://openqa.suse.de/tests/1173431

PR updated.

Test module code can be found here: https://github.com/yxususe/os-autoinst-distri-opensuse/blob/proxyscc_postreg/tests/console/suseconnect_scc.pm

A new test scenario will be created. Verification testrun: http://f146.suse.de/tests/1352 http://f146.suse.de/tests/1353

As discussed with yi and riafarov I reminded about the suggestions in the ticket description. I recommend to try a test plan that should look as simple as:

• boot_to_desktop
• suseconnect_scc

and another test suite with:

• boot_to_desktop
• yast_scc

If necessary add additional modules - but only if necessary - e.g. sle15_workarounds or consoletest_setup or hostname. If the above is done - but only after it's done - you can add more test modules, e.g. "zypper_lr" to list the enabled repositories.

PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3595
Verification testrun: http://f146.suse.de/tests/1392 http://f146.suse.de/tests/1392

PR updated. Verification testruns are: http://f146.suse.de/tests/1454 http://f146.suse.de/tests/1455
At the moment the test fails because the repos couldn't be refreshed.

Testsuites are added. However cannot be executed yet because qcow images are not available.

failed as incomplete on zkvm: https://openqa.suse.de/tests/1209421

Please make sure to not keep scenarios that end up incomplete

https://openqa.suse.de/tests/1209422#step/boot_to_desktop/2 is the failing scenario you added for zVM. This cannot work as zVM instances can not boot disk images. Also the scenario does not state 'START_AFTER_TEST. This won't work. I suggest to use the "test development" job group for experiments.

Keep in mind though that jobs should not incomplete. If that is the case then they are incorrectly configured. Rather they should cancel if the parent job fails to provide a qcow image, which they do: https://openqa.suse.de/tests/1213106
So ok up to now. Also most recent build 303.1 could not provide a qcow image so understandable that we are blocked by this still.
A workaround is to retrigger an older build which still worked.

@yi please update the ticket description with more recent tasks and an effort estimation according to the template as we also have it in other tickets.

Atm the test fails at boot_to_desktop since it didn't boot to desktop but only text mode:
https://openqa.suse.de/tests/1226927#step/boot_to_desktop/6

However I couldn't reproduce it locally, reasons: when I copied the job, it is scheduled after skip_registration, which already fails at first_boot, so that the test couldn't continue.

Besides that, can anyone tell me the reason for scheduling it after skip_registration?

Trying with DESKTOP=textmode:
geekotest@shaka:~> /usr/share/openqa/script/clone_job.pl --from https://openqa.suse.de --host https://openqa.suse.de --skip-download --skip-deps 1226927 DESKTOP=textmode _GROUP=0 TEST=postreg_scc_yxu_tryout_with_desktop_textmode
Created job #1227554: sle-15-Installer-DVD-x86_64-Build310.1-minimal+proxy_SCC-postreg_SUSEconnect@64bit

There's dependency issues between modules, the source code should be fixed.

Yes, I think either use @mnowak's code or in case of suseconnect_scc.pm instead of

foreach (values %registration::SLE15_MODULES) {
    assert_script_run "SUSEConnect -p sle-module-" . lc($_) . "/$version/$arch";
}

it should be

foreach (split(',', $registration::SLE15_DEFAULT_MODULES{get_required_var('SLE_PRODUCT')})) {
    assert_script_run "SUSEConnect -p sle-module-" . lc($registration::SLE15_MODULES{$_}) . "/$version/$arch";
}

(code not verified)

to

1. use the default modules only
2. support all products
3. use the correct order of modules

"time inestimably": Easy suggestion: When you can't find a time estimation stop work immediately. What's the sense to start a work when you don't know if you can ever finish? I think you can find an effort estimation (not duration) with a <optimistic>-<pessimistic> range.

"…because of other dependent issues": which ones?

yi: issue was mentioned in comment 31, now resolved.

PTF submitted. Now I will try to adapt the code form sccreg.pm.

I had a look of lib/suseconnect_register.pm, it will be more complicated to call one function command_register from there, since it uses SCC_ADDONS as the queue of modules to be registered and the modules are also kept in hash.

Another look at jeos/sccreg.pm: it is very similar to console/suseconnect_scc.pm, the only difference is that the modules for jeos are: ('basesystem', 'scripting', 'legacy'), so there should be a way to reduce code redundancy here actually. However this PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3776 should fix the problem for now.

Verification testruns on osd: http://openqa.suse.de/tests/1230963 http://openqa.suse.de/tests/1230964

the scenario "yast_scc" can not work this way as the HDD image does not provide yast (and should not). I removed the scenario from the functional job group and instead moved it to Test Development: SLE 15 (64bit only). The suseconnect scenario for zkvm was incomplete because there is no "skip_registration@zkvm", only "skip_registration@s390x-kvm". Added the corresponding scenario to Test Development: SLE 15 as well.

Providing a basis: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3781
A lot to be improved yet.

Oliver, the content of SLE15_MODULES and SLE15_DEFAULT_MODULES are different, and the naming matters: http://openqa.suse.de/tests/1230963#step/suseconnect_scc/16 . Could you explain why you are using SLE15_DEFAULT_MODULES instead of SLE15_MODULES? And I think the easiest way is still to define the modules just in an array.

Hi Sergio, I have separated the scenario minimal+proxy_SCC-postreg_yast_scc in another ticket: https://progress.opensuse.org/issues/26984
And since you are already working on it, I assigned it to you. Thanks.

Last verification on osd failed although on my local machine succeeded. New verification: http://openqa.suse.de/tests/1233670

That's good! The last job within the QA SLE functional job group https://openqa.suse.de/tests/1233455 failed however to boot an image. Ideas why?

Because the needle was lost? It couldn't boot. Should there some more parameters be specified? But on aarch64 it succeeded: https://openqa.suse.de/tests/1233047#step/boot_to_desktop/1

https://openqa.suse.de/tests/1233455#step/boot_to_desktop/2 does not look like any needle was lost

Verified with build 321.5:
https://openqa.suse.de/tests/1236202
https://openqa.suse.de/tests/1235877
https://openqa.suse.de/tests/1235712