Project

General

Profile

action #97772

[migration][zypper_migration][qem][maint] test fails in zypper_migration - test keeps failing after related bug is closed as fixed

Added by vsvecova 9 months ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
dzedro
Category:
Bugs in existing tests
Target version:
QA - QE-Core: Ready
Start date:
2021-08-31
Due date:
% Done:

100%

Estimated time:
Difficulty:

Description

This failure has been occurring still, even though the related bug (bsc#1183744) has been closed and verified as fixed for several months already.

Observation

openQA test in scenario sle-15-SP1-Server-DVD-HA-Incidents-x86_64-qam_ha_rolling_upgrade_migration_node01@64bit fails in
zypper_migration

Test suite description

The base test suite is used for job templates defined in YAML documents. It has no settings of its own.

Reproducible

Fails since (at least) Build :16502:rubygem-actionpack-5_1

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest

History

#1 Updated by okurz 9 months ago

  • Subject changed from [zypper_migration][qem][maint] test fails in zypper_migration - test keeps failing after related bug is closed as fixed to [migration][zypper_migration][qem][maint] test fails in zypper_migration - test keeps failing after related bug is closed as fixed

oh, I just found this ticket minutes after I reopened https://bugzilla.suse.com/show_bug.cgi?id=1183744 as the reminder comments in https://bugzilla.suse.com/show_bug.cgi?id=1183744 also point to openQA jobs which show what look like exactly the same problem as originally that the option "-D" is not understood.

Adding "[migration]" team keyword as this looks to be a "migration" specific problem.

#2 Updated by openqa_review 8 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: qam_ha_rolling_upgrade_migration_node01
https://openqa.suse.de/tests/7071144

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

#3 Updated by vsvecova 8 months ago

I wonder if this test wouldn't be better off removed for the time being, as it is not bringing much value while it's constantly failing, and it has been breaking automated approvals for the qam-openqa review group.

bsc#1183744 is currently still open and I assume it is going to take some time till someone gets around to fixing it.

Edit: I realized that the correct bug is most likely bsc#1184347 (not 1183744), so I reopened it and updated with a comment.

#4 Updated by jadamek 8 months ago

As it's clearly a bug and not an infra or test issue, if the test is removed, I'm not sure someone will pay attention and will add it back to the jobgroup. But this is just my point a view, do like you usually do.

#5 Updated by dzedro 8 months ago

  • Status changed from New to In Progress
  • Assignee set to dzedro

#6 Updated by dzedro 8 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Workaround implemented, but don't know how this issue will be solved for customers.

#7 Updated by dzedro 8 months ago

  • Target version set to QE-Core: Ready

Also available in: Atom PDF