action #69349
closed[functional][y] setting QEMUVGA=cirrus invalid for aarch64 on remote_vnc_controller: auto_review:"qemu-system-aarch64: Cirrus VGA not available"
0%
Description
Observation¶
https://openqa.suse.de/tests/4482765# shows
can't open qmp at /usr/lib/os-autoinst/OpenQA/Qemu/Proc.pm line 432.
[0m[33m[2020-07-24T12:53:20.328 UTC] [info] ::: OpenQA::Qemu::Proc::save_state: Saving QEMU state to qemu_state.json
[0m[37m[2020-07-24T12:53:20.332 UTC] [debug] flushing frames
[0m[37m[2020-07-24T12:53:20.569 UTC] [debug] QEMU: QEMU emulator version 3.1.1.1 (openSUSE Leap 15.1)
[0m[37m[2020-07-24T12:53:20.570 UTC] [debug] QEMU: Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
[0m[37m[2020-07-24T12:53:20.570 UTC] [debug] QEMU: qemu-system-aarch64: Cirrus VGA not available
as the test scenario has set QEMUVGA=cirrus
this showed up in https://gitlab.suse.de/openqa/auto-review/-/jobs/236942 but not in previous pipelines. This seems to be a regression introduced just yesterday on 2020-07-24
Updated by riafarov over 3 years ago
- Status changed from New to Rejected
- Assignee set to okurz
Thanks for the info. We are on stage to create image, and it's tracked in #68708
Also, we have test development job group for this purpose, so I don't understand how this is High priority. I do understand that it pollutes monitoring results, but failures in that job group are more than expected.
Updated by okurz over 3 years ago
riafarov wrote:
Thanks for the info. We are on stage to create image, and it's tracked in #68708
Also, we have test development job group for this purpose, so I don't understand how this is High priority. I do understand that it pollutes monitoring results, but failures in that job group are more than expected.
Well, maybe we can introduce an exception in the monitoring rules to exclude any testing job group. I set to "High" for a couple of reasons: 1. It was just recently introduced. Looking into it sooner will make it more likely that one remembers what the intention with adding the job was, 2. As you correctly stated it pollutes monitoring results and a common problem with alerting frameworks is that people get alarm fatigue easily so I am trying to apply a disciplined approach to ensure alerts are attended properly. However, the most urgent issue I handled with the special text string in the ticket subject line auto_review:"…" so that https://gitlab.suse.de/openqa/auto-review/ can label the job automatically.
Updated by okurz over 3 years ago
- Related to action #68708: [functional][y] Generate support_server image for SLES on aarch64 added