Project

General

Profile

action #50297

[functional][y][investigation][timeboxed:6h] test fails in system_role, system doesn't get key pressed

Added by riafarov about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2019-04-11
Due date:
2019-06-04
% Done:

0%

Estimated time:
Difficulty:

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

History

#1 Updated by oorlov about 3 years ago

  • Due date changed from 2019-05-07 to 2019-04-23
  • Status changed from New to Workable

#2 Updated by riafarov about 3 years ago

  • Due date changed from 2019-04-23 to 2019-05-07

#3 Updated by ybonatakis about 3 years ago

  • Status changed from Workable to In Progress
  • Assignee set to ybonatakis

#4 Updated by riafarov about 3 years ago

Similar issue with other page of the wizard: https://openqa.suse.de/tests/2823696

#5 Updated by ybonatakis about 3 years ago

  • 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

#6 Updated by JRivrain about 3 years ago

  • 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.

#7 Updated by JERiveraMoya about 3 years ago

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".

#8 Updated by JERiveraMoya about 3 years ago

@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.

#9 Updated by JERiveraMoya about 3 years ago

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.

#10 Updated by JERiveraMoya about 3 years ago

  • Assignee changed from ybonatakis to JERiveraMoya

#11 Updated by JERiveraMoya about 3 years ago

  • 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.

#12 Updated by riafarov about 3 years ago

  • 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.

#13 Updated by riafarov almost 3 years ago

  • 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