action #50297
closed
[functional][y][investigation][timeboxed:6h] test fails in system_role, system doesn't get key pressed
Added by riafarov almost 6 years ago.
Updated over 5 years ago.
Category:
Bugs in existing tests
Description
Observation¶
Seems that issue is not sporadic, failed multiple times. In the logs we can see that alt-n is actually send to the SUT, but we don't get to the partitioning page.
We need to investigate and potentially apply workaround.
openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-allmodules+allpatterns@64bit fails in
system_role
Test suite description¶
Maintainer: jrauch
Perform an installation enabling all modules and selecting all patterns.
This test suite always registers to have access to all modules.
Reproducible¶
Fails since (at least) Build 212.1
Expected result¶
Last good: VR_iob (or more recent)
Further details¶
Always latest result in this scenario: latest
- Due date changed from 2019-05-07 to 2019-04-23
- Status changed from New to Workable
- Due date changed from 2019-04-23 to 2019-05-07
- Status changed from Workable to In Progress
- Assignee set to ybonatakis
- Status changed from In Progress to Resolved
I couldnt find the cause of it after multiple job executions. The cloned jobs passed successfully most of the times when i run against the local openqa, or they failed in different module than system_role. I am not sure that there is something to be done. The frame is blocked for a some time. Seems that sending the keys twice, the button is functional. I am going to resolve this ticket based on the above observations.
I cant say if this is a qemu issue related but my WS has qemu version 3.1.0-6.9 and OSD has version 2.9.1(SUSE Linux Enterprise 12) at the moment of the investigation.
feel free to reopen it in any case
- Status changed from Resolved to Feedback
This is still happening very frequently, a follow-up ticket should be created, or this one re-opened: probably a 6 hours investigation was not enough. I put this in feedback, since the investigation was done already. Then we can decide what to do next.
According to @coolo:
3:42:23 PM - jrivera: hi! in case of this kind of warning raised by os-autoins " WARNING: check_asserted_screen took 0.87 seconds for 39 candidate needles - make your needles more specific" is any way to solve it without touching needles? it looks like is detecting too many candidates...
3:47:45 PM - coolo: jrivera: you need to tag the needles and exclude tags in the distribution - so no way without touching needles
3:51:36 PM - jrivera: it looks like this warning is avoid to send key alt-n: https://openqa.suse.de/tests/2854646#step/system_role/1 Could that be possible?
3:52:36 PM - jrivera: coolo: in particular this has: ENV-15ORLATER-1
3:54:01 PM - coolo: jrivera: the problem is that most of the candidates will not have 15ORLATER-0 so it's not discarded
3:54:09 PM - coolo: only sle12 will ignore the ORLATER
3:54:19 PM - coolo: but noone bothered to tag the sle12 needles to be ignored on 15
3:56:00 PM - jrivera: coolo: ENV-15ORLATER-0 means that the flag is false? I see, thanks, we will take a look
So according to that, tagging sle15 needles that should be ignored should help to avoid that "saturation".
@JRivrain let's take a look together next working day, probably we need to ask some further questions and check carefully to not provoke any disaster with needles :) Feel free to change the assignee if we move forward with this idea.
I did a cleanup of needles that were not matching in system_role module, removing the warning completely. I could not apply tag ENV-15ORLATER-0 due it applied to all candidate needles. Despite that the problem persists and alt-n does not take effect: https://openqa.suse.de/tests/2862785
Comparing previous successful result for allmodules+allpatterns test suite, I can see that we are including module phub now.
- Assignee changed from ybonatakis to JERiveraMoya
- Due date changed from 2019-05-07 to 2019-05-21
- Status changed from Feedback to Workable
- Assignee deleted (
JERiveraMoya)
Let's give opportunity to someone else to pick it.
- Due date changed from 2019-05-21 to 2019-06-04
- Priority changed from Normal to High
We need to take a look before all the logs are vanished, as we might get same issue later on for SP2.
- Status changed from Workable to Resolved
- Assignee set to riafarov
Same story as in #50399. As of now keep collecting occurrences, but not much we can do and issue is not that severe.
Also available in: Atom
PDF