action #108995
closedcoordination #121876: [epic] Handle openQA review failures in Yam squad - SLE 15 SP5
test fails in yast_users- timeout
0%
Description
Observation¶
This test module sporadically times-out on aarch64, we could try to see if it's a performance issue in the product, and if not increase the timeout
openQA test in scenario sle-15-SP4-Online-aarch64-yast2_cmd@aarch64 fails in
yast_users
Test suite description¶
QAM team has developed some tests using YaST cmd line, which is less costly to execute and maintain. This test suite is using those test modules for QA SLE functional.
Reproducible¶
Fails since (at least) Build 113.1
Expected result¶
Last good: 108.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Suggestions¶
Check progress in #107326
Updated by JRivrain about 2 years ago
- Project changed from openQA Tests to qe-yam
- Category deleted (
Bugs in existing tests)
Updated by JERiveraMoya about 2 years ago
- Tags deleted (
qe-yast-refinement) - Description updated (diff)
- Status changed from New to Workable
Updated by rainerkoenig about 2 years ago
This issue should be fixed after applying QEMURAM=4096 for poo#107326.
Updated by JERiveraMoya about 2 years ago
- Status changed from Workable to Feedback
Updated by JERiveraMoya about 2 years ago
- Related to action #107326: command `dig www.opensuse.org +short` fails in yast_dns_server only in aarch64 added
Updated by JERiveraMoya about 2 years ago
- Status changed from Feedback to Workable
- Assignee deleted (
rainerkoenig)
Let's move it back to backlog as it might require different approach.
Updated by openqa_review almost 2 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: yast2_cmd
https://openqa.suse.de/tests/8685672#step/yast_users/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 40 days if nothing changes in this ticket.
Updated by openqa_review almost 2 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: yast2_cmd
https://openqa.suse.de/tests/8762244#step/yast_users/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 112 days if nothing changes in this ticket.
Updated by hjluo almost 2 years ago
Now the original job was removed. https://openqa.suse.de/tests/8293653
Updated by hjluo almost 2 years ago
- Status changed from Workable to In Progress
Updated by JERiveraMoya over 1 year ago
- Status changed from In Progress to Workable
- Assignee deleted (
hjluo)
Updated by openqa_review over 1 year ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: yast2_cmd
https://openqa.suse.de/tests/8762244#step/yast_users/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- 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.
Updated by rainerkoenig over 1 year ago
- Status changed from Workable to In Progress
- Assignee set to rainerkoenig
Updated by JERiveraMoya over 1 year ago
could you please describe the current situation?
as you noticed this ticket didn't pass by refinement and as expected 18 days later there is no actual result.
we should resolve it as investigation ticket and file another one with low prio with findings to check in the future.
Updated by JERiveraMoya over 1 year ago
could you please link the ticket with the finding and resolve this one? thx.
Updated by rainerkoenig over 1 year ago
Status of investigation¶
- Problem occurs sproadically, even after setting higher QEMURAM and patching the test, so that a real timeout is provided that then could be prolonged by TIMEOUT_SCALE setting.
- In Build 38.1 we now see this sporadic issue also on x86_64 architecture.
Updated by JERiveraMoya over 1 year ago
could you please label that job in development with a new ticket where you put this investigation and resolve this one?
Updated by rainerkoenig over 1 year ago
- Status changed from In Progress to Resolved
Further investigation of this issue is done in #120223.