action #108995
closed
coordination #121876: [epic] Handle openQA review failures in Yam squad - SLE 15 SP5
test fails in yast_users- timeout
Added by JRivrain about 2 years ago.
Updated over 1 year ago.
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
- Project changed from openQA Tests to qe-yam
- Category deleted (
Bugs in existing tests)
- Tags set to qe-yast-refinement
- Target version set to Current
- Tags deleted (
qe-yast-refinement)
- Description updated (diff)
- Status changed from New to Workable
This issue should be fixed after applying QEMURAM=4096 for poo#107326.
- Status changed from Workable to Feedback
- Assignee set to rainerkoenig
- Related to action #107326: command `dig www.opensuse.org +short` fails in yast_dns_server only in aarch64 added
Happened again in last build
- Status changed from Feedback to Workable
- Assignee deleted (
rainerkoenig)
Let's move it back to backlog as it might require different approach.
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.
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.
- Status changed from Workable to In Progress
- Status changed from In Progress to Workable
- Assignee deleted (
hjluo)
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.
- Status changed from Workable to In Progress
- Assignee set to rainerkoenig
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.
could you please link the ticket with the finding and resolve this one? thx.
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.
could you please label that job in development with a new ticket where you put this investigation and resolve this one?
- Status changed from In Progress to Resolved
Further investigation of this issue is done in #120223.
- Parent task set to #121876
Also available in: Atom
PDF