QA » openQA Project » openQA Tests

Observation¶

openQA test in scenario sle-15-Installer-DVD-s390x-suse_patches-systemd_testsuite@s390x-kvm-sle12 fails in
bootloader_zkvm
but also in many others now which I assume is the same cause.

The error from the autoinst-log.txt is:

[2018-05-10T16:06:44.0883 CEST] [debug] Command executed: virsh  destroy openQA-SUT-4 |& grep -v "\(failed to get domain\|Domain not found\)"
[2018-05-10T16:06:44.0954 CEST] [debug] Command executed: virsh  undefine --snapshots-metadata openQA-SUT-4 |& grep -v "\(failed to get domain\|Domain not found\)"
[2018-05-10T16:06:45.0022 CEST] [debug] Command executed: virsh  define /var/lib/libvirt/images/openQA-SUT-4.xml
[2018-05-10T16:06:45.0056 CEST] [debug] Command's stderr:
error: Failed to define domain from /var/lib/libvirt/images/openQA-SUT-4.xml
error: unsupported configuration: unknown on_reboot action: destroydestroy
[2018-05-10T16:06:45.0212 CEST] [debug] # Test died: {
  'json_cmd_token' => 'iinPxkkJ',
  'args' => [],
  'console' => 'svirt',
  'function' => 'define_and_start'
}
virsh define failed at /usr/lib/os-autoinst/consoles/sshVirtsh.pm line 487.

Reproducible¶

Also reported by dehai in #qa-review:

[10 May 2018 04:45:44] <dehai> mgriessmeier: okurz: most of s390x cases are failed by  bootloader_zkvm , is it worker performance issue? because it has gone for some builds. please see below status in the latest build 611.1, thanks!

Looks like this is a recently introduced problem, a retrigger usually seems to work.

Acceptance criteria¶

• AC1: The failure test popup also reports the line "error: unsupported configuration: unknown on_reboot action: destroydestroy"
• AC2: Error does not appear anymore with good statistics

Suggestions¶

• Check with "domain experts", maybe they changed something recently?
• Make sure the error output is also forwarded to the text popups
• Investigate further what are the differences between "good" and "bad" jobs
• Optional: Improve the code to provide less warnings/errors which are part of normal behaviour

Further details¶

Always latest result in this scenario: latest