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

https://bugzilla.suse.com/show_bug.cgi?id=1215203 opened

https://bugzilla.suse.com/show_bug.cgi?id=1215203#c3

Thomas Schmidt asked for:
Please remove sle-module-legacy-release and sle-we-release then before de-registration.
both got installed not via SCC. This is root cause.

IMO this test is failing because the initial SUSEConnect -d failed, the failure should be not ignored. https://openqa.suse.de/tests/12348448#step/suseconnect/3

to test my changes:

 # We have sometimes issue 'suseconnect -d' because 'sle-module-legacy-release' or 'sle-we-release' got installed, not via SCC 
 # See bsc#1215203 fro more details. Remove it before de-registration as a workaround
 zypper_call 'rm sle-module-legacy-release sle-we-release';

see
http://10.168.192.143/tests/25#step/suseconnect/3
and http://10.168.192.143/tests/25#step/suseconnect/7
is still failing at same place as before.

Please stop messing with packages manually, as we discussed, the issue is in SUSEConnect -d on line 31 which can fail silently.
This issue is just consequence of that silent failure at beginning.

http://10.168.192.143/tests/26#step/suseconnect/27

shows all installed products, some are not registered.

# wait_serial expected: qr/DsP0N-\d+-/u
# Result:

Installed Products:
------------------------------------------

  SUSE Linux Enterprise Server 15 SP5
  (SLES/15.5/x86_64)

  Registered

    Subscription:

    Name: SUSE Employee subscription for SUSE Linux Enterprise Server x86_64
    Regcode: XXXXXXX
    Starts at: 2023-03-29 09:25:34 UTC
    Expires at: 2024-03-29 09:25:34 UTC
    Status: ACTIVE
    Type: internal


------------------------------------------

  Basesystem Module
  (sle-module-basesystem/15.5/x86_64)

  Registered


------------------------------------------

  Desktop Applications Module
  (sle-module-desktop-applications/15.5/x86_64)



------------------------------------------

  Server Applications Module
  (sle-module-server-applications/15.5/x86_64)

  Registered


------------------------------------------

  Development Tools Module
  (sle-module-development-tools/15.5/x86_64)



------------------------------------------

  Python 3 Module
  (sle-module-python3/15.5/x86_64)

  Registered


------------------------------------------

DsP0N-0-

For example: sle-module-desktop-applications, sle-module-development-tools

compare

https://openqa.suse.de/tests/12077910#step/suseconnect/3

Error: Registration server returned 'Cannot deactivate the product "Server Applications Module". Other activated products depend upon it.' (422)

or later https://openqa.suse.de/tests/12077910#step/suseconnect/43

Error: Registration server returned 'SUSE Linux Enterprise Workstation Extension is not yet activated on the system.' (422)

with successful test runs
https://openqa.suse.de/tests/12067108#step/suseconnect/3
or the latest https://openqa.suse.de/tests/12144776#step/suseconnect/3

that the error code 422 doesn't lead to fail:

Error: Registration server returned 'Cannot deactivate the product "Basesystem Module". Other activated products depend upon it.' (422)

We can say that assert_script_run won't fail because of these errors, this is silently "failure", which leads later failure?
For suseconnect -d this is correct behavior for de-registration.

The question is what should we do if packages got installed, not via scc?
Any suggestions are welcome.

I think there is a difference between assert_script_run "SUSEConnect -d ||:"; and assert_script_run "SUSEConnect -d ";
See successful test run on my openQA: http://10.168.192.143/tests/31

I would do cleanup when SUSEConnect -d will fail
If SUSEConnect -d can fail at beginning then it can fail also at the end.
https://dzedro.suse.cz/tests/1857

--- a/tests/console/suseconnect.pm
+++ b/tests/console/suseconnect.pm
@@ -28,8 +28,7 @@ sub run {
     select_serial_terminal;

     # Make sure to start with de-registered system. In case the system is not registered this command will fail
-    assert_script_run "SUSEConnect -d ||:";
-    assert_script_run "SUSEConnect --cleanup";
+    assert_script_run "SUSEConnect -d || SUSEConnect --cleanup";
     assert_script_run "SUSEConnect --status-text";

     zypper_call 'lr';
@@ -44,7 +43,7 @@ sub run {
     add_suseconnect_product(is_sle('<15') ? 'sle-live-patching' : 'sle-module-live-patching', undef, undef, "-r $live_reg_code");

     assert_script_run "SUSEConnect --status";
-    assert_script_run "SUSEConnect -d";
+    assert_script_run "SUSEConnect -d || SUSEConnect --cleanup";
     assert_script_run "SUSEConnect --status-text";

dzedro wrote in #note-10:

I would do cleanup when SUSEConnect -d will fail
If SUSEConnect -d can fail at beginning then it can fail also at the end.
https://dzedro.suse.cz/tests/1857

--- a/tests/console/suseconnect.pm
+++ b/tests/console/suseconnect.pm
@@ -28,8 +28,7 @@ sub run {
     select_serial_terminal;

     # Make sure to start with de-registered system. In case the system is not registered this command will fail
-    assert_script_run "SUSEConnect -d ||:";
-    assert_script_run "SUSEConnect --cleanup";
+    assert_script_run "SUSEConnect -d || SUSEConnect --cleanup";
     assert_script_run "SUSEConnect --status-text";

     zypper_call 'lr';
@@ -44,7 +43,7 @@ sub run {
     add_suseconnect_product(is_sle('<15') ? 'sle-live-patching' : 'sle-module-live-patching', undef, undef, "-r $live_reg_code");

     assert_script_run "SUSEConnect --status";
-    assert_script_run "SUSEConnect -d";
+    assert_script_run "SUSEConnect -d || SUSEConnect --cleanup";
     assert_script_run "SUSEConnect --status-text";

yes. I found out now why this is failed sporadic (see comment_#9) So I will change my code so, thanks!

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17922
will run a couple of tests on OSD.