action #128501
closed[security] [QR] [IPMI] test fails in consoletest_setup on @64bit-ipmi
100%
Description
Observation¶
openQA test in scenario sle-15-SP4-Online-QR-x86_64-fips_env_mode_tests_crypt_tool_intel_ipmi@64bit-ipmi fails in
consoletest_setup
Happens in fips_env_mode_tests_crypt_web_intel_ipmi@64bit-ipmi on consoletest_setup as well.
Test suite description¶
Testsuite maintained at https://gitlab.suse.de/qe-security/osd-sle15-security.
Reproducible¶
Fails since (at least) Build 183.10
Expected result¶
Last good: 179.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by emiler over 1 year ago
- Status changed from New to In Progress
- Assignee set to emiler
The issue is caused by IPMI backend, since the test is green on all other platforms and behaves sporadically.
Updated by emiler over 1 year ago
- Subject changed from [security] [QR] test fails in consoletest_setup on @64bit-ipmi to [security] [QR] [IPMI] test fails in consoletest_setup on @64bit-ipmi
- Category changed from Bugs in existing tests to Infrastructure
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
An explanation has been given by Oliver Kurz:
As with IPMI you control a specific bare-metal machine the results can differ significantly and there could be multiple reasons for a problem. First thing I suggest is to lookup the bare-metal machine behind the openQA worker instance. In the case of the above job it's
grenache-1:16
. If you are logged in and follow the link to the worker you will get https://openqa.suse.de/admin/workers/1247 which shows up asix64ph1075
. There was just a specific ticket about that https://progress.opensuse.org/issues/128654 which I just resolved as the machine showed up to be super-stable after I rebooted one of the involved network switches on 2023-05-05 13:08Z, 5 days ago. If you saw problems with the specific machine after that date please make sure there is an open ticket with detailed description about that.
It appears other teams are affected as well. More info in the original Slack thread.
Workers should be OK now and if not, we should file a new ticket for the specific worker. Waiting for new QR runs.
Updated by emiler over 1 year ago
- Related to action #128654: [sporadic] Fail to create an ipmi session to worker grenache-1:16 (ix64ph1075) in its vlan added
Updated by emiler over 1 year ago
- Status changed from Feedback to Resolved
I restarted the test (and parent) and it is passing.
https://openqa.suse.de/tests/11085627
Closing.
Updated by openqa_review over 1 year ago
- Status changed from Resolved to Feedback
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: fips_env_mode_tests_crypt_web_intel_ipmi@64bit-ipmi
https://openqa.suse.de/tests/11085628#step/consoletest_setup/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 openqa_review about 1 year ago
- Status changed from Resolved to Feedback
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: fips_env_mode_tests_crypt_tool_intel_ipmi@64bit-ipmi
https://openqa.suse.de/tests/11575645#step/consoletest_setup/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 60 days if nothing changes in this ticket.