Project

General

Profile

action #122029

[sporadic] test fails in cockpit_service

Added by ggardet_arm 3 months ago. Updated 8 days ago.

Status:
Closed
Priority:
High
Assignee:
jlausuch
Target version:
-
Start date:
2022-12-15
Due date:
% Done:

0%

Estimated time:
Difficulty:
Tags:
qac, bug

Description

Observation

openQA test in scenario alp-0.1-kvm-aarch64-alp_default@aarch64 fails in
cockpit_service

Test suite description

ALP image boot with ignition disk and default tests. Default tests are transactional-update, rebootmgr, health_check, cockpit service and some other checks specific to transactional servers.

Installation fails quite often with network issues, such as:

Retrieving: dmidecode-3.4-4.7.aarch64.rpm [error]
Download (curl) error for 'https://download.opensuse.org/repositories/SUSE:/ALP/standard/aarch64/dmidecode-3.4-4.7.aarch64.rpm':
Error code: Curl error 92
Error message: HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

Abort, retry, ignore? [a/r/i/...? shows all options] (a):

Reproducible

Fails since (at least) Build 20221213

Expected result

Last good: 20221212 (or more recent)

Further details

Always latest result in this scenario: latest

History

#1 Updated by maritawerner 3 months ago

  • Tags set to qac

#2 Updated by jlausuch 3 months ago

In the previous run, I see that it failed at a different stage:
https://openqa.opensuse.org/tests/2955255#step/cockpit_service/16

Retrieving: libopus0-1.3.1-4.8.aarch64.rpm [error]
Download (curl) error for 'https://download.opensuse.org/repositories/SUSE:/ALP/standard/aarch64/libopus0-1.3.1-4.8.aarch64.rpm':
Error code: Curl error 92
Error message: HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

Could this be due to aarch64 repo changing while tests are running? (just guessing)

#3 Updated by ggardet_arm 3 months ago

jlausuch wrote:

In the previous run, I see that it failed at a different stage:
https://openqa.opensuse.org/tests/2955255#step/cockpit_service/16

Retrieving: libopus0-1.3.1-4.8.aarch64.rpm [error]
Download (curl) error for 'https://download.opensuse.org/repositories/SUSE:/ALP/standard/aarch64/libopus0-1.3.1-4.8.aarch64.rpm':
Error code: Curl error 92
Error message: HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

Could this be due to aarch64 repo changing while tests are running? (just guessing)

I do not think so, because it would rather throw an "RPM not found" error.
x86_64 is also affected by the way.

#5 Updated by ggardet_arm 3 months ago

  • Subject changed from test fails in cockpit_service to [sporadic] test fails in cockpit_service

jlausuch wrote:

Problem solved?
https://openqa.opensuse.org/tests/2959110#step/cockpit_service/16

No, it is sporadic.

#6 Updated by jlausuch 3 months ago

  • Tags changed from qac to qac, bug
  • Project changed from openQA Tests to MicroOS / SLE Micro
  • Category deleted (Bugs in existing tests)
  • Status changed from New to Workable
  • Priority changed from Normal to High

#7 Updated by jlausuch 3 months ago

  • Project changed from MicroOS / SLE Micro to ALP

#8 Updated by okurz 3 months ago

The issue might be due to the mirror infrastructure or inconsistent state of the local zypper cache. I see the upstream feature request for zypper https://github.com/openSUSE/zypper/issues/420 related which should help but it does not look like the idea is accepted nor will be implemented anytime soon. But of course you can retry within the test code, e.g. explicitly call zypper refresh and then again transactional-update to pick up the updated metadata.

#9 Updated by jlausuch 3 months ago

  • Status changed from Workable to In Progress
  • Assignee set to jlausuch

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16135

I am not sure about he root cause of this, maybe some race condition of OBS package vs test execution time, or even that the package is being updated in download.opensuse.org at execution time.... Let's see what happens if we add zypper ref before installing the package, just to make sure the repo metadata is up to date before installation.

#10 Updated by openqa_review 2 months ago

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

This bug is still referenced in a failing openQA test: alp_default
https://openqa.opensuse.org/tests/3044446#step/cockpit_service/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

#11 Updated by slo-gin about 1 month ago

This ticket was set to High priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

#12 Updated by jlausuch 8 days ago

  • Status changed from In Progress to Closed

Closing, this is from previous ALP prototype. We have now new images, so this doesn't apply any more. If this happens again, let's re-open or create new ticket.

Also available in: Atom PDF