Project

General

Profile

action #69349

[functional][y] setting QEMUVGA=cirrus invalid for aarch64 on remote_vnc_controller: auto_review:"qemu-system-aarch64: Cirrus VGA not available"

Added by okurz about 2 years ago. Updated about 2 years ago.

Status:
Rejected
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2020-07-25
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

https://openqa.suse.de/tests/4482765# shows

can't open qmp at /usr/lib/os-autoinst/OpenQA/Qemu/Proc.pm line 432.

[2020-07-24T12:53:20.328 UTC] [info] ::: OpenQA::Qemu::Proc::save_state: Saving QEMU state to qemu_state.json
[2020-07-24T12:53:20.332 UTC] [debug] flushing frames
[2020-07-24T12:53:20.569 UTC] [debug] QEMU: QEMU emulator version 3.1.1.1 (openSUSE Leap 15.1)
[2020-07-24T12:53:20.570 UTC] [debug] QEMU: Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
[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


Related issues

Related to qe-yast - action #68708: [functional][y] Generate support_server image for SLES on aarch64Resolved2020-07-072020-08-11

History

#1 Updated by riafarov about 2 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.

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

#3 Updated by okurz about 2 years ago

  • Related to action #68708: [functional][y] Generate support_server image for SLES on aarch64 added

Also available in: Atom PDF