Project

General

Profile

Actions

action #48947

closed

[functional][opensuse][y] test fails in yast2_lan - race condition, pop up appears after multi tag assertion

Added by lnussel about 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 24
Start date:
2019-03-11
Due date:
2019-04-23
% Done:

0%

Estimated time:
3.00 h
Difficulty:

Description

Observation

openQA test in scenario opensuse-15.1:S:A-Staging-DVD-x86_64-cryptlvm@64bit fails in
yast2_lan

Test suite description

Maintainers: okurz

This looks like a race condition. The wrong needle matches even though the popup is there.

Pop-up with 'Networkmanager_controlled' tag does not appear immediately, so yast2_lan manages to match first and assumes that network configuration is controlled by wicked, which is not the case.

There should be already some wrapper to check symlink for the network service.

Suggestions

We can check if network is controlled by wicked or NM and make our expectations more strict, so that we assert that pop-up is shown in case of NM and test will fail if it's shown, but network is controlled by wicked.

Reproducible

Fails since (at least) Build 214.1 (current job)

Expected result

Last good: 213.6 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by SLindoMansilla about 5 years ago

  • Subject changed from test fails in yast2_lan to [functional][opensuse] test fails in yast2_lan

As a result of backlog triaging (see https://progress.opensuse.org/projects/openqatests/wiki#ticket-backlog-triaging for more information).

Please, feel free to adjust the category or the "[label]" if you think different.

Actions #2

Updated by SLindoMansilla about 5 years ago

  • Subject changed from [functional][opensuse] test fails in yast2_lan to [functional][opensuse][y] test fails in yast2_lan
Actions #3

Updated by SLindoMansilla about 5 years ago

  • Subject changed from [functional][opensuse][y] test fails in yast2_lan to [functional][opensuse][y] test fails in yast2_lan - race condition, pop up appears after multi tag assertion
Actions #4

Updated by riafarov about 5 years ago

  • Due date set to 2019-04-09
  • Target version set to Milestone 23
Actions #5

Updated by riafarov about 5 years ago

  • Description updated (diff)
Actions #6

Updated by riafarov about 5 years ago

  • Target version changed from Milestone 23 to Milestone 24
Actions #7

Updated by riafarov about 5 years ago

  • Description updated (diff)
  • Estimated time set to 3.00 h
Actions #8

Updated by riafarov about 5 years ago

  • Status changed from New to Workable
Actions #9

Updated by riafarov about 5 years ago

  • Description updated (diff)
Actions #10

Updated by JRivrain about 5 years ago

  • Assignee set to JRivrain
Actions #11

Updated by JRivrain about 5 years ago

I made it simple, there is an existing function called is_network_manager_default. I t is pretty dumb though, it only checks if we are on Opensuse where we have NM as default. I had first done a check with systemctl that worked, and thought I'd rather put that function in a parent script like y2_common, but then discovered the existing function which is simpler.

test will fail if it's shown, but network is controlled by wicked.

It does fail now in that case: http://amazing.suse.cz/tests/5896#step/yast2_lan/18

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

Actions #12

Updated by JRivrain about 5 years ago

  • Status changed from Workable to Feedback
Actions #13

Updated by JRivrain about 5 years ago

The PR had to be reverted because it looks like we cannot rely on the function is_network_manager_default: it is irrelevant in various cases such as https://openqa.opensuse.org/tests/898369#step/yast2_lan/11 and https://openqa.opensuse.org/tests/898103#.. In those cases (upgrade and generic desktop on TW) Opensuse defaults to wicked. That function is used by yast2_lan_hostname and yast2_network_settings, so I'm surprised it did not cause problems earlier. I want to investigate a bit on this, and of course create a new PR, so I put the ticket back to "in progress".

Actions #14

Updated by JRivrain about 5 years ago

  • Status changed from Feedback to In Progress
Actions #15

Updated by riafarov about 5 years ago

  • Due date changed from 2019-04-09 to 2019-04-23
Actions #17

Updated by JRivrain about 5 years ago

  • Status changed from In Progress to Feedback
Actions #18

Updated by riafarov about 5 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF