QA » openQA Project » openQA Tests

Has not been seen since then
Current build
https://openqa.opensuse.org/tests/621710
Triggered 50 runs on pinky to generate statistics -> http://pinky.arch.suse.de/tests

Appeared a few times, would suggest reducing the typing limit in ensure_installed / x11_start_program (not sure which one applies here)

Setting to blocked by:
https://progress.opensuse.org/issues/31687
Reason:
We have no real check if the entered text is actually what we wanted to enter and even if we knew it x11_start_program lacks a proper error handling.
Will try to find a proper solution in blocker ticket, then this should become obsolete

blocker has been resolved, moving to next sprint as workable

The expected result is clearly that the test runs stable so removing the [research] tag even though it might involve some research, just research is not enough.

I see two options here:

1. we merge the WIP PR and create a needle for the typed text
2. we are happy that it did not happen for a long time and close this without merging the PR

What do you think?

jorauch wrote:

I see two options here:

1. we merge the WIP PR and create a needle for the typed text

We will merge the PR only after it is not WIP anymore, obviously. The question there still holds: What makes inkscape special?

1. we are happy that it did not happen for a long time and close this without merging the PR

That is not true because I could easily find a recent failure: https://openqa.opensuse.org/tests/664611#step/inkscape/4

jorauch wrote:
I see two options here:
we merge the WIP PR and create a needle for the typed text
We will merge the PR only after it is not WIP anymore, obviously. The question there still holds: What makes inkscape special?

Appearantly it's special because its failing regularly and we have a ticket for it.
When comparing the recent fail you posted with the inital issue we can see that it fails in different steps, but both are caused by x11_start_program
Maybe we should go a step back and try to harden x11_start_program before we fix symptoms all around our tests?

Talked with okurz.

Our assumption: The upgrade systems have a "dirty" filesystem causing e.g. btrfs maintenance tasks to slow down the systems more than clean installation jobs. Then random test modules fail, e.g. inkscape.

To separate the concerns we have the following ideas:

• Add new test suite "dirty system test" with normal timeout and explicit check for system responsiveness, e.g. starting krunner very often and check for the suggestions to popup (best directly after reboot)
• update tests with TIMEOUT_SCALE=3 to exclude workload problems

lnussel wrote:

the force_cron_run test is meant to take care of triggering all cron jobs so they don't disturb later.

That's true, but still we see the update cases are more prone to fail for reason yet unknown. Could also be that the krunner itself needs more time to rebuild some cache or so. This is why I think #35877 could help. Don't you think?

Additionally the force_cron_run is useless if we reboot in the meantime

PR created:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5000

Waiting for merge and consequences in production

blocker resolved, moving to workable into next sprint (to be revisited in planning meeting)

Please try to check statistics again.

no reaction. Feel free to unassign sooner, no problem to give tickets back to the backlog. As well as in other tickets, blocked by #31351

With blockers resolved within #35685 I did some statistical analysis in #35685#note-37 and found four out of 100 jobs failing in shutdown , could be more, some still running.

https://openqa.opensuse.org/tests/700813#step/shutdown/18 failed after the previous module, reboot, failed so let us discard that one for now, as well as https://openqa.opensuse.org/tests/700863#step/shutdown/19 for the same reason. https://openqa.opensuse.org/tests/700814#step/shutdown/4 as well as https://openqa.opensuse.org/tests/700864#step/shutdown/4 fail for what looks like the same error, that is: xterm does not open from the plasma desktop runner. My hypothesis for the root cause is higher system load after the bootup caused by the reboot module. This is why we moved it originally to further back in the schedule. Somehow we need to ensure that the desktop runner is handled more gracefully in the shutdown module after reboot but waiting for the desktop runner longer within the shutdown module itself sounds wrong as this would make the module more dependant on the previous module. Maybe call the code from "desktop_runner" in reboot after the bootup to ensure the desktop runner is responsive in followup modules?

merged and stable. Missing failures ar handled elsewhere, e.g. gnucash in #38387, chromium in #36304