action #46394
open[sle][s390x][spvm][kvm][sporadic] test fails in various modules to login to svirt console (or system is not up yet)
0%
Description
Observation¶
openQA test in scenario sle-15-SP1-Installer-DVD-s390x-btrfs@s390x-kvm-sle12 fails in
reconnect_mgmt_console
Reproducible¶
Fails sporadically since Build 144.3 (current job, first time occurence)
Expected result¶
Last good: 143.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Workaround¶
Restart the job.
Updated by okurz almost 6 years ago
- Subject changed from [sle][functional][u][s390x][kvm] test fails in reconnect_mgmt_console to login or system is not up yet to [sle][functional][u][s390x][spvm][kvm] test fails in reconnect_mgmt_console to login or system is not up yet
Same for ppc64le spvm?: https://openqa.suse.de/tests/2385648#step/reconnect_mgmt_console/3 -> retriggered https://openqa.suse.de/tests/2387097 is fine
Updated by okurz almost 6 years ago
- Subject changed from [sle][functional][u][s390x][spvm][kvm] test fails in reconnect_mgmt_console to login or system is not up yet to [sle][functional][u][s390x][spvm][kvm] test fails in reconnect_mgmt_console (or logs_from_installation_system) to login or system is not up yet
same in https://openqa.suse.de/tests/2385851#step/logs_from_installation_system/3 it seems -> retriggered https://openqa.suse.de/tests/2387098 is fine
Updated by okurz almost 6 years ago
And https://openqa.suse.de/tests/2385932#step/reconnect_mgmt_console/10 -> retriggered https://openqa.suse.de/tests/2387257 is fine
Maybe it's a product bug that something is way slower now?
Further failures:
- https://openqa.suse.de/tests/2385845 -> retriggered as https://openqa.suse.de/tests/2387295 is fine
- https://openqa.suse.de/tests/2385890#step/bootloader_zkvm/13 -> retriggered https://openqa.suse.de/tests/2387370 is fine
Now https://openqa.suse.de/tests/2385900#step/shutdown/8 is interesting because the SUT did not shutdown in time. Maybe this can tell us something. -> retriggered https://openqa.suse.de/tests/2387317 is fine
Updated by okurz almost 6 years ago
- Status changed from In Progress to Workable
- Assignee deleted (
okurz) - Priority changed from Urgent to High
So the "Urgency" is reduced I would say because the issue is not that severe from retriggers but my suspicion is that either grenache or the hypervisor host(s) might be too loaded to respond in time to the ssh connection attempts which I recommend to look in in more detail, e.g. better statistics.
Updated by mgriessmeier almost 6 years ago
- Status changed from Workable to In Progress
- Assignee set to mgriessmeier
every failing test which I've found was running on 18th of January between 10 and 12 GMT - I highly assume we had a temporary hiccup in the network which caused those ssh logins to be slower...
I recommend to reject/resolve for now... or lower priority
Updated by okurz almost 6 years ago
- Priority changed from High to Normal
Ok, let's lower prio but I guess the problem was caused by high load due to the milestone candidate being tested. We could wait until the next milestone candidate and check again at this time. However, what we could try is to trigger many tests at the same time, e.g. the usual way for "statisticial investigation", for i in {001..100}; …
Actually let me just do that, because it's weekend :)
-> https://openqa.suse.de/tests/overview?build=okurz_investigation&version=15-SP1&distri=sle
Updated by mgriessmeier almost 6 years ago
okurz wrote:
Ok, let's lower prio but I guess the problem was caused by high load due to the milestone candidate being tested. We could wait until the next milestone candidate and check again at this time. However, what we could try is to trigger many tests at the same time, e.g. the usual way for "statisticial investigation",
for i in {001..100}; …Actually let me just do that, because it's weekend :)
-> https://openqa.suse.de/tests/overview?build=okurz_investigation&version=15-SP1&distri=sle
well done - two of them (in different modules though) show similiar symptoms:
https://openqa.suse.de/tests/2404940#step/bootloader_zkvm/13
https://openqa.suse.de/tests/2404891#step/hostname_inst/4
Updated by mgriessmeier almost 6 years ago
hmm, what I wonder is - we have the function handle_password_prompt
but it actually never checks if the login worked correctly - so everything what comes after typing the password is handled in the following step (which differs a lot in different scenarios)
e.g. on s390x-kvm we check next if the initrd was downloaded correctly.
So it might make sense to assert_screen the actual login - I'll try that out
Updated by mgriessmeier almost 6 years ago
santi brought in the valid point that this could be also a key press (ret) missed
Updated by szarate almost 6 years ago
Seems to be happening in more places https://openqa.suse.de/tests/2440046#step/kdump_and_crash/59 and https://openqa.suse.de/tests/2440094#step/system_prepare/3
Updated by mgriessmeier almost 6 years ago
- Priority changed from Normal to High
happens more often on initial trigger of a new build now - increasing prio
Updated by mgriessmeier almost 6 years ago
- Subject changed from [sle][functional][u][s390x][spvm][kvm] test fails in reconnect_mgmt_console (or logs_from_installation_system) to login or system is not up yet to [sle][functional][u][s390x][spvm][kvm] test fails in various modules to login to svirt console (or system is not up yet)
Updated by okurz almost 6 years ago
- Target version changed from Milestone 22 to Milestone 23
Updated by okurz almost 6 years ago
- Related to action #47450: [qam] test fails in bootloader_zkvm on s390x added
Updated by okurz almost 6 years ago
- Related to action #48215: [sle][functional][u] test fails in bootloader_zkvm - zkvm host is not ready added
Updated by okurz almost 6 years ago
- Related to deleted (action #48215: [sle][functional][u] test fails in bootloader_zkvm - zkvm host is not ready)
Updated by okurz almost 6 years ago
- Has duplicate action #48215: [sle][functional][u] test fails in bootloader_zkvm - zkvm host is not ready added
Updated by okurz almost 6 years ago
- Related to action #46964: [functional][u][s390x] test fails in the middle of execution (not installation) as incomplete with "half-open socket?" – connection to machine vanished? added
Updated by okurz almost 6 years ago
- Related to action #48260: [sle][functional][u][s390x][kvm] test fails in reboot_after_installation - "The console isn't responding correctly. Maybe half-open socket?" added
Updated by okurz almost 6 years ago
- Has duplicate action #45065: [functional][u][s390x][kvm] test fails in hostname_inst on switch to terminal, waiting for password but login does not happen added
Updated by okurz almost 6 years ago
- Has duplicate action #46832: [tools][u][sporadic] test fails in logs_from_installation_system: stuck at ssh password prompt added
Updated by okurz almost 6 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: offline_sles12sp4_scc_tcm+wsm_all_full**
https://openqa.suse.de/tests/2493362
Updated by okurz almost 6 years ago
- Related to action #45515: [sle][migration][sle15sp1]test fails in patch_sle - failed login on ttysclp0 added
Updated by okurz almost 6 years ago
- Related to action #48830: [sle][functional][u] test fails in hostname_inst - cannot reach inst-console added
Updated by okurz almost 6 years ago
- Related to deleted (action #48830: [sle][functional][u] test fails in hostname_inst - cannot reach inst-console)
Updated by okurz almost 6 years ago
- Has duplicate action #48830: [sle][functional][u] test fails in hostname_inst - cannot reach inst-console added
Updated by mgriessmeier almost 6 years ago
okurz wrote:
still "In Progress"?
ahh you know - I'm a procrastinator sometimes - working tomorrow for a better today!
100 jobs triggered for statistical investigation: https://openqa.suse.de/tests/overview?distri=sle&build=mgriessmeier_poo46394&version=15-SP1
Updated by SLindoMansilla over 5 years ago
- Has duplicate action #49700: [functional][u] test fails in kdump_and_crash: ssh re-login doesn't happen on s390 added
Updated by okurz over 5 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: minimal+base
https://openqa.suse.de/tests/2745238
Updated by mgriessmeier over 5 years ago
- Status changed from In Progress to Workable
- Assignee deleted (
mgriessmeier) - Target version changed from Milestone 23 to Milestone 24
moving to M24, unassigning
probably related to recent work by szarate
Updated by zluo over 5 years ago
- Status changed from Workable to In Progress
- Assignee set to zluo
take over and checking
Updated by zluo over 5 years ago
it seems not able to reproduce this issue atm.
To check: https://openqa.suse.de/tests/2769025#next_previous
Updated by SLindoMansilla over 5 years ago
- Subject changed from [sle][functional][u][s390x][spvm][kvm] test fails in various modules to login to svirt console (or system is not up yet) to [sle][functional][u][s390x][spvm][kvm][sporadic] test fails in various modules to login to svirt console (or system is not up yet)
- Description updated (diff)
It is sporadic.
I can find this: sle-15-SP1-Installer-DVD-s390x-Build205.1-gnome@s390x-kvm-sle12: https://openqa.suse.de/tests/2767119#step/bootloader_zkvm/17
Updated by zluo over 5 years ago
this is an known issue for bootloader_zkvm at very beginning which reported many times and you're working on https://progress.opensuse.org/issues/45326 ?
I checked the test results and I see reconnect_mgmt_console failed one time: https://openqa.suse.de/tests/2768973#step/reconnect_mgmt_console/18
hostname_inst failed for same reason: https://openqa.suse.de/tests/2768976#step/hostname_inst/6
I think the re-login is not working sporadic for zkvm host. This could be a network issue.
Updated by SLindoMansilla over 5 years ago
That zKVM error happens from time to time when libvirtd is running for long time. And it is necessary to reboot it on the SUT host.
But, I don't understand what you mean. Do you say that you found this issue while reproducing or that sle-15-SP1-Installer-DVD-s390x-Build205.1-gnome@s390x-kvm-sle12: https://openqa.suse.de/tests/2767119#step/bootloader_zkvm/17 is this bug? It is not that bug, "Cannot allocate memory" is not in the logs. It is also about this sporadic issue that we don't yet know why it happens.
Updated by zluo over 5 years ago
https://openqa.suse.de/tests/2767119#step/bootloader_zkvm/17 the issue not a bug. This is more an issue on zkvm side:
https://openqa.suse.de/tests/2767119/file/autoinst-log.txt
...
[2019-04-03T09:48:09.902 CEST] [debug] >>> testapi::_check_backend_response: match=initrd-saved timed out after 30 (assert_screen)
[2019-04-03T09:48:10.532 CEST] [debug] no candidate needle with tag(s) 'initrd-saved' matched
[2019-04-03T09:48:10.550 CEST] [debug] /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/installation/bootloader_zkvm.pm:90 called testapi::select_console
[2019-04-03T09:48:10.551 CEST] [debug] <<< testapi::select_console(testapi_console='svirt')
[2019-04-03T09:48:10.961 CEST] [debug] Connection to root@s390p8.suse.de established
/usr/lib/os-autoinst/consoles/vnc_base.pm:58:{
'hostname' => 'localhost',
'ikvm' => 0,
'port' => 49239
}
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":54263"
after 20538 requests (20537 known processed) with 0 events remaining.
xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":54263"
...
Updated by zluo over 5 years ago
- Status changed from In Progress to Rejected
check test results for https://openqa.suse.de/tests/2769025#next_previous and my local tests: http://f40.suse.de/tests/3239#next_previous
we have actually 2 failures of 200 test runs.
I see that is more likely a setup issue on zkvm or a network issue to zkvm side.
Reject this for now.
Updated by SLindoMansilla over 5 years ago
- Description updated (diff)
- Status changed from Rejected to Workable
- Assignee deleted (
zluo)
Please, only reject issues that are not reproducible.
Sporadic issues should only be rejected by team consensus.
This is something that hit us in every build. We cannot reject it.
If there is a bug in zkvm, we need to file a bug for it.
If it is a network isue, we need to investigate why this happens to adapt the svirt backend properly or to fix our test infrastructure.
Updated by zluo over 5 years ago
This is something that hit us in every build. We cannot reject it.
- No, this is not happened almost for 2 months.
If there is a bug in zkvm, we need to file a bug for it.
- I don't see any indication for bug and we don't have monitoring logs for network on zkvm.
If it is a network isue, we need to investigate why this happens to adapt the svirt backend properly or to fix our test infrastructure.
- network issue on osd, this is really hard to fix.
I would suggest to work on https://progress.opensuse.org/issues/45326 at first. If we can fix this issue, then we might be able to understand the sporadic problem with login to svirt console.
Updated by SLindoMansilla over 5 years ago
This is from 2 days ago: https://openqa.suse.de/tests/2767119#step/bootloader_zkvm/17
How did you look for this issue? If you looked for jobs that failed in module reconnect_mgmt_console of course you found less. But, as the subject line mentions "fails in various modules to login to svirt console or system is not up yet".
Updated by SLindoMansilla over 5 years ago
- Related to action #49958: [functional][u][s390x] test fails in reboot_after_installation - Failed to destroy domain openQA-SUT- added
Updated by okurz over 5 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: toolchain_zypper
https://openqa.suse.de/tests/2816748
Updated by zluo over 5 years ago
- Status changed from Workable to In Progress
- Assignee set to zluo
take over and check the current status
Updated by zluo over 5 years ago
over 100 test runs over weekend don't show any issue:
http://f40.suse.de/tests/3598#next_previous
check test runs on osd:
https://openqa.suse.de/tests/2862903#next_previous
but qcow2 image on osd got removed :( so test all failed!
Updated by zluo over 5 years ago
need to check test runs on osd (for spvm): https://openqa.suse.de/tests/2863091#next_previous
Updated by zluo over 5 years ago
found known issue:
https://bugzilla.suse.com/show_bug.cgi?id=1112682
Updated by zluo over 5 years ago
- Status changed from In Progress to Rejected
This issue is not reproducible on osd at moment.
All test runs were successful except bootloader failed due to a known issue.
Updated by okurz over 5 years ago
- Status changed from Rejected to Workable
- Assignee deleted (
zluo) - Target version changed from Milestone 24 to Milestone 25
QSF-u grooming: Reopening as still an issue, duplicated by #49958
suspicion by mgriessmeier: Network in QA-lab could be the bottleneck causing a jam. Potential solution: Move production openQA infrastructure, e.g. grenache and openqaw5-xen, out of QA lab
Updated by okurz over 5 years ago
- Has duplicate action #50048: [functional][u][y][sporadic] test fails in sle15_workarounds added
Updated by okurz over 5 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: online_sles15_pscc_basesys+srv+wsm_def_full_zdup
https://openqa.suse.de/tests/2925055
Updated by okurz over 5 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: online_sles15_pscc_basesys+srv+wsm_def_full_zdup
https://openqa.suse.de/tests/2925055
Updated by coolgw over 5 years ago
Issue happen many times on new 12sp5 migration check, please take a look
"Resource temporarily unavailable" found in each of following cases
https://openqa.suse.de/tests/3021272/file/autoinst-log.txt
https://openqa.suse.de/tests/3021273/file/autoinst-log.txt
https://openqa.suse.de/tests/3021271/file/autoinst-log.txt
https://openqa.suse.de/tests/3018748/file/autoinst-log.txt
https://openqa.suse.de/tests/3018750/file/autoinst-log.txt
Updated by mgriessmeier over 5 years ago
coolgw wrote:
Issue happen many times on new 12sp5 migration check, please take a look
"Resource temporarily unavailable" found in each of following cases
https://openqa.suse.de/tests/3021272/file/autoinst-log.txt
https://openqa.suse.de/tests/3021273/file/autoinst-log.txt
https://openqa.suse.de/tests/3021271/file/autoinst-log.txt
https://openqa.suse.de/tests/3018748/file/autoinst-log.txt
https://openqa.suse.de/tests/3018750/file/autoinst-log.txt
those are different issues: #45326
Updated by mgriessmeier over 5 years ago
- Priority changed from Normal to High
- Target version changed from Milestone 25 to Milestone 26
Updated by okurz over 5 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: online_sles15_pscc_basesys+srv+wsm_def_full_zdup
https://openqa.suse.de/tests/2925055
Updated by coolgw over 5 years ago
Updated by SLindoMansilla over 5 years ago
- Has duplicate action #52958: [functional][u] test fails in reconnect_mgmt_console - Test failed to enter password and log into the svirt console added
Updated by okurz over 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
Updated by okurz over 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
Updated by mgriessmeier over 5 years ago
- Target version changed from Milestone 26 to Milestone 27
Updated by SLindoMansilla over 5 years ago
- Assignee set to mgriessmeier
- Estimated time set to 42.00 h
Move grenache
Updated by SLindoMansilla over 5 years ago
- Has duplicate action #54419: [sle][functional]test fails in bootloader_zkvm - host seems to have problem or is not ready added
Updated by vsvecova over 5 years ago
Found an example of similar behavior, from the research here on progress.o.o. I assume they could be related to this one:
https://openqa.suse.de/tests/3315127#step/bootloader_zkvm/21
From log: https://openqa.suse.de/tests/3315127/file/autoinst-log.txt
[2019-08-31T01:46:00.100 CEST] [debug] Command's stderr:
error: failed to get domain 'openQA-SUT-1'
error: Domain not found: no domain with matching name 'openQA-SUT-1'
Another one manifests similar symptoms, but found on kvm:
https://openqa.suse.de/tests/3315136#step/await_install/1
[2019-08-31T01:40:07.501 CEST] [debug] Command's stderr:
error: Failed to destroy domain openQA-SUT-3
error: Requested operation is not valid: domain is not running
Could the second one also be related? Or does it warrant its own ticket? I haven't found an existing one.
Updated by mgriessmeier over 5 years ago
- Target version changed from Milestone 27 to Milestone 28
vsvecova wrote:
Found an example of similar behavior, from the research here on progress.o.o. I assume they could be related to this one:
https://openqa.suse.de/tests/3315127#step/bootloader_zkvm/21
From log: https://openqa.suse.de/tests/3315127/file/autoinst-log.txt[2019-08-31T01:46:00.100 CEST] [debug] Command's stderr: error: failed to get domain 'openQA-SUT-1' error: Domain not found: no domain with matching name 'openQA-SUT-1'Another one manifests similar symptoms, but found on kvm:
https://openqa.suse.de/tests/3315136#step/await_install/1
[2019-08-31T01:40:07.501 CEST] [debug] Command's stderr: error: Failed to destroy domain openQA-SUT-3 error: Requested operation is not valid: domain is not runningCould the second one also be related? Or does it warrant its own ticket? I haven't found an existing one.
first one for sure,
second one looks more like disk space full or something
Updated by okurz about 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
Updated by okurz about 5 years ago
- Related to action #36126: [functional][u] post_fail_hook matches on "text_login_root" before actual tty switch and therefore never logs in added
Updated by okurz about 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by okurz about 5 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: ssh-X@ppc64le-spvm
https://openqa.suse.de/tests/3507040
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"
- The label in the openQA scenario is removed
Updated by okurz about 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by okurz about 5 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: ssh-X@ppc64le-spvm
https://openqa.suse.de/tests/3576044
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"
- The label in the openQA scenario is removed
Updated by okurz about 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by okurz about 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by okurz about 5 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: ssh-X@ppc64le-spvm
https://openqa.suse.de/tests/3576044
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"
- The label in the openQA scenario is removed
Updated by okurz about 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by okurz about 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by mgriessmeier almost 5 years ago
- Target version changed from Milestone 28 to Milestone 31
Updated by okurz almost 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by okurz almost 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by okurz almost 5 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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743
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"
- The label in the openQA scenario is removed
Updated by okurz almost 5 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: offline_sled15sp1_pscc_basesys_desk-we-dev-py2_all_full
https://openqa.suse.de/tests/3978043
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"
- The label in the openQA scenario is removed
Updated by hjluo almost 5 years ago
- Related to action #59172: [sle][Migration][SLE15SP2] test fails in zypper_patch - failed to switch to desktop added
Updated by okurz almost 5 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: offline_sles15_pscc_lp-basesys-srv-desk-dev-contm-lgm-wsm_all_full
https://openqa.suse.de/tests/4032554
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"
- The label in the openQA scenario is removed
Updated by openqa_review over 4 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: online_sles15sp1_pscc_basesys-srv_all_full_y_spvm@ppc64le-spvm
https://openqa.suse.de/tests/4096397
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"
- The label in the openQA scenario is removed
Updated by okurz over 4 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: online_sles15_pscc_basesys-srv-desk-we-py2_all_full_zypp
https://openqa.suse.de/tests/4203383
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"
- The label in the openQA scenario is removed
Updated by SLindoMansilla over 4 years ago
- Subject changed from [sle][functional][u][s390x][spvm][kvm][sporadic] test fails in various modules to login to svirt console (or system is not up yet) to [sle][s390x][spvm][kvm][sporadic] test fails in various modules to login to svirt console (or system is not up yet)
- Assignee deleted (
mgriessmeier)
Updated by okurz over 4 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: online_sled15sp1_pscc_basesys_desk_we_py2_all_full_zypp
https://openqa.suse.de/tests/4328538
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"
- The label in the openQA scenario is removed
Updated by okurz over 3 years ago
- Priority changed from High to Normal
This ticket was set to "High" priority but was not updated within 120 days which is 4 times the period of the SLO for "High" tickets (30 days) as described on https://progress.opensuse.org/projects/openqatests/wiki/Wiki#SLOs-service-level-objectives . The ticket will be set to the next lower priority of "Normal".
Updated by slo-gin over 2 years ago
This ticket was set to Normal 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.
Updated by okurz over 1 year ago
- Related to coordination #131519: [epic] Additional redundancy for OSD virtualization testing added
Updated by slo-gin 9 months ago
This ticket was set to Normal 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.