Project

General

Profile

Actions

action #46394

open

[sle][s390x][spvm][kvm][sporadic] test fails in various modules to login to svirt console (or system is not up yet)

Added by okurz about 5 years ago. Updated over 1 year ago.

Status:
Workable
Priority:
Normal
Assignee:
-
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 31
Start date:
Due date:
% Done:

0%

Estimated time:
42.00 h
Difficulty:

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.


Related issues 16 (0 open16 closed)

Related to openQA Tests - action #47450: [qam] test fails in bootloader_zkvm on s390xResolved2019-02-12

Actions
Related to openQA Tests - action #46964: [functional][u][s390x] test fails in the middle of execution (not installation) as incomplete with "half-open socket?" – connection to machine vanished?Resolvedokurz2019-02-01

Actions
Related to openQA Tests - action #48260: [sle][functional][u][s390x][kvm] test fails in reboot_after_installation - "The console isn't responding correctly. Maybe half-open socket?"Resolvedokurz2019-02-21

Actions
Related to openQA Tests - action #45515: [sle][migration][sle15sp1]test fails in patch_sle - failed login on ttysclp0Resolvedhjluo2018-12-24

Actions
Related to openQA Tests - action #49958: [functional][u][s390x] test fails in reboot_after_installation - Failed to destroy domain openQA-SUT-Rejectedokurz2019-04-03

Actions
Related to openQA Tests - action #36126: [functional][u] post_fail_hook matches on "text_login_root" before actual tty switch and therefore never logs inResolvedzluo2018-05-14

Actions
Related to openQA Tests - action #59172: [sle][Migration][SLE15SP2] test fails in zypper_patch - failed to switch to desktopRejectedhjluo2019-11-07

Actions
Related to openQA Infrastructure - coordination #131519: [epic] Additional redundancy for OSD virtualization testingResolvedokurz2023-02-09

Actions
Has duplicate openQA Tests - action #48215: [sle][functional][u] test fails in bootloader_zkvm - zkvm host is not readyRejectedokurz2019-02-21

Actions
Has duplicate openQA Tests - action #45065: [functional][u][s390x][kvm] test fails in hostname_inst on switch to terminal, waiting for password but login does not happenRejectedokurz2018-12-12

Actions
Has duplicate openQA Tests - action #46832: [tools][u][sporadic] test fails in logs_from_installation_system: stuck at ssh password promptRejectedokurz2019-01-29

Actions
Has duplicate openQA Tests - action #48830: [sle][functional][u] test fails in hostname_inst - cannot reach inst-consoleRejectedokurz2019-03-07

Actions
Has duplicate openQA Tests - action #49700: [functional][u] test fails in kdump_and_crash: ssh re-login doesn't happen on s390RejectedSLindoMansilla2019-03-26

Actions
Has duplicate openQA Tests - action #50048: [functional][u][y][sporadic] test fails in sle15_workaroundsRejectedokurz2019-04-05

Actions
Has duplicate openQA Tests - action #52958: [functional][u] test fails in reconnect_mgmt_console - Test failed to enter password and log into the svirt consoleRejectedSLindoMansilla2019-06-12

Actions
Has duplicate openQA Tests - action #54419: [sle][functional]test fails in bootloader_zkvm - host seems to have problem or is not readyRejected2019-07-18

Actions
Actions #1

Updated by okurz about 5 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
Actions #2

Updated by okurz about 5 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
Actions #3

Updated by okurz about 5 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:

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

Actions #4

Updated by okurz about 5 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.

Actions #5

Updated by mgriessmeier about 5 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

Actions #6

Updated by okurz about 5 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

Actions #7

Updated by mgriessmeier about 5 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

Actions #8

Updated by mgriessmeier about 5 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

Actions #9

Updated by mgriessmeier about 5 years ago

santi brought in the valid point that this could be also a key press (ret) missed

Actions #11

Updated by mgriessmeier about 5 years ago

  • Priority changed from Normal to High

happens more often on initial trigger of a new build now - increasing prio

Actions #12

Updated by mgriessmeier about 5 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)
Actions #13

Updated by okurz about 5 years ago

  • Target version changed from Milestone 22 to Milestone 23
Actions #14

Updated by okurz about 5 years ago

  • Related to action #47450: [qam] test fails in bootloader_zkvm on s390x added
Actions #15

Updated by okurz about 5 years ago

  • Related to action #48215: [sle][functional][u] test fails in bootloader_zkvm - zkvm host is not ready added
Actions #16

Updated by okurz about 5 years ago

  • Related to deleted (action #48215: [sle][functional][u] test fails in bootloader_zkvm - zkvm host is not ready)
Actions #17

Updated by okurz about 5 years ago

  • Has duplicate action #48215: [sle][functional][u] test fails in bootloader_zkvm - zkvm host is not ready added
Actions #18

Updated by okurz about 5 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
Actions #19

Updated by okurz about 5 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
Actions #20

Updated by okurz about 5 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
Actions #21

Updated by okurz about 5 years ago

  • Has duplicate action #46832: [tools][u][sporadic] test fails in logs_from_installation_system: stuck at ssh password prompt added
Actions #22

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_sles12sp4_scc_tcm+wsm_all_full**
https://openqa.suse.de/tests/2493362

Actions #23

Updated by okurz about 5 years ago

  • Related to action #45515: [sle][migration][sle15sp1]test fails in patch_sle - failed login on ttysclp0 added
Actions #24

Updated by okurz about 5 years ago

  • Related to action #48830: [sle][functional][u] test fails in hostname_inst - cannot reach inst-console added
Actions #25

Updated by okurz about 5 years ago

  • Related to deleted (action #48830: [sle][functional][u] test fails in hostname_inst - cannot reach inst-console)
Actions #26

Updated by okurz about 5 years ago

  • Has duplicate action #48830: [sle][functional][u] test fails in hostname_inst - cannot reach inst-console added
Actions #27

Updated by okurz about 5 years ago

still "In Progress"?

Actions #28

Updated by mgriessmeier about 5 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

Actions #29

Updated by SLindoMansilla almost 5 years ago

  • Has duplicate action #49700: [functional][u] test fails in kdump_and_crash: ssh re-login doesn't happen on s390 added
Actions #30

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: minimal+base
https://openqa.suse.de/tests/2745238

Actions #31

Updated by mgriessmeier almost 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

Actions #32

Updated by zluo almost 5 years ago

  • Status changed from Workable to In Progress
  • Assignee set to zluo

take over and checking

Actions #33

Updated by zluo almost 5 years ago

it seems not able to reproduce this issue atm.

To check: https://openqa.suse.de/tests/2769025#next_previous

Actions #34

Updated by SLindoMansilla almost 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

Actions #35

Updated by zluo almost 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.

Actions #36

Updated by SLindoMansilla almost 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.

Actions #37

Updated by zluo almost 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"
...

Actions #38

Updated by zluo almost 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.

Actions #39

Updated by SLindoMansilla almost 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.

Actions #40

Updated by zluo almost 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.

Actions #41

Updated by SLindoMansilla almost 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".

Actions #42

Updated by SLindoMansilla almost 5 years ago

  • Related to action #49958: [functional][u][s390x] test fails in reboot_after_installation - Failed to destroy domain openQA-SUT- added
Actions #43

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: toolchain_zypper
https://openqa.suse.de/tests/2816748

Actions #44

Updated by zluo almost 5 years ago

issue on worker: grenache-1:14, grenache-1:12

Actions #45

Updated by zluo almost 5 years ago

  • Status changed from Workable to In Progress
  • Assignee set to zluo

take over and check the current status

Actions #46

Updated by zluo almost 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!

Actions #47

Updated by zluo almost 5 years ago

need to check test runs on osd (for spvm): https://openqa.suse.de/tests/2863091#next_previous

Actions #49

Updated by zluo almost 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.

Actions #50

Updated by okurz almost 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

Actions #51

Updated by okurz almost 5 years ago

  • Has duplicate action #50048: [functional][u][y][sporadic] test fails in sle15_workarounds added
Actions #52

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: online_sles15_pscc_basesys+srv+wsm_def_full_zdup
https://openqa.suse.de/tests/2925055

Actions #53

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+wsm_def_full_zdup
https://openqa.suse.de/tests/2925055

Actions #56

Updated by mgriessmeier over 4 years ago

  • Priority changed from Normal to High
  • Target version changed from Milestone 25 to Milestone 26
Actions #57

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+wsm_def_full_zdup
https://openqa.suse.de/tests/2925055

Actions #59

Updated by SLindoMansilla over 4 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
Actions #60

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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743

Actions #61

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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743

Actions #62

Updated by mgriessmeier over 4 years ago

  • Target version changed from Milestone 26 to Milestone 27
Actions #63

Updated by SLindoMansilla over 4 years ago

  • Assignee set to mgriessmeier
  • Estimated time set to 42.00 h

Move grenache

Actions #64

Updated by SLindoMansilla over 4 years ago

  • Has duplicate action #54419: [sle][functional]test fails in bootloader_zkvm - host seems to have problem or is not ready added
Actions #65

Updated by vsvecova over 4 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.

Actions #66

Updated by mgriessmeier over 4 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 running

Could 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

Actions #67

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: offline_sles12sp3_media_sdk_def_full_s390x
https://openqa.suse.de/tests/2918743

Actions #68

Updated by okurz over 4 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
Actions #69

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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #70

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: ssh-X@ppc64le-spvm
https://openqa.suse.de/tests/3507040

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"
  3. The label in the openQA scenario is removed
Actions #71

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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #72

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: ssh-X@ppc64le-spvm
https://openqa.suse.de/tests/3576044

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"
  3. The label in the openQA scenario is removed
Actions #73

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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #74

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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #75

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: ssh-X@ppc64le-spvm
https://openqa.suse.de/tests/3576044

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"
  3. The label in the openQA scenario is removed
Actions #76

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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #77

Updated by okurz about 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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #78

Updated by mgriessmeier about 4 years ago

  • Target version changed from Milestone 28 to Milestone 31
Actions #79

Updated by okurz about 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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #80

Updated by okurz about 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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #81

Updated by okurz about 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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #82

Updated by okurz about 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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #83

Updated by hjluo about 4 years ago

  • Related to action #59172: [sle][Migration][SLE15SP2] test fails in zypper_patch - failed to switch to desktop added
Actions #84

Updated by okurz almost 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: 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:

  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"
  3. The label in the openQA scenario is removed
Actions #85

Updated by openqa_review almost 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:

  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"
  3. The label in the openQA scenario is removed
Actions #86

Updated by okurz almost 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:

  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"
  3. The label in the openQA scenario is removed
Actions #87

Updated by SLindoMansilla almost 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)
Actions #88

Updated by okurz almost 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:

  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"
  3. The label in the openQA scenario is removed
Actions #89

Updated by okurz over 2 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".

Actions #90

Updated by slo-gin over 1 year 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.

Actions #91

Updated by okurz 9 months ago

  • Related to coordination #131519: [epic] Additional redundancy for OSD virtualization testing added
Actions

Also available in: Atom PDF