Project

General

Profile

Actions

action #41429

closed

[functional][y] test fails in yast2_network_setup - another case related to NM is the default network management

Added by mlin7442 over 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA (private) - Milestone 19
Start date:
2018-09-21
Due date:
2018-10-09
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-extra_tests_on_gnome@64bit fails in
yast2_network_setup

Reproducible

Fails since (at least) Build 20180911

Expected result

Last good: 20180910 (or more recent)

Further details

Always latest result in this scenario: latest


Related issues 3 (0 open3 closed)

Related to openQA Tests (public) - action #40049: [functional][y] test fails in yast2_network_setup - need better logging w/o network to create product issueResolvedriafarov2018-08-212018-09-25

Actions
Related to openQA Tests (public) - action #40766: [functional][y] test fails in yast2_network_settingsResolvedJERiveraMoya2018-09-102018-09-25

Actions
Has duplicate openQA Tests (public) - action #41564: [functional][y] test fails in yast2_network_setupRejectedokurz2018-09-252018-10-09

Actions
Actions #1

Updated by okurz over 6 years ago

  • Subject changed from test fails in yast2_network_setup - another case related to NM is the default network management to [functional][y] test fails in yast2_network_setup - another case related to NM is the default network management
  • Due date set to 2018-10-23
  • Status changed from New to Workable
  • Target version set to Milestone 20

I assume we should adapt the test module to accept the notice that NetworkManager is active and execute the subset of tests from the module that make sense in this scenario. Or: Whenever we detect this dialog we switch to wicked and then execute the normal path.

@mlin7442 we can ask the team QSF-y for help but we are straining their nerves and ressources when we ask them to fix what someone else broke. In my opinion I would not have ignored this test failure for a release of Tumbleweed but would have reverted the submission for the change to NetworkManager after we found all failing tests, let the tests be fixed in a careful way and then resubmit the change to the product. An alternative of course can always be an extension of the staging projects. What do you think?

Actions #2

Updated by okurz over 6 years ago

  • Related to action #40049: [functional][y] test fails in yast2_network_setup - need better logging w/o network to create product issue added
Actions #3

Updated by riafarov over 6 years ago

  • Related to action #40766: [functional][y] test fails in yast2_network_settings added
Actions #4

Updated by okurz over 6 years ago

  • Has duplicate action #41564: [functional][y] test fails in yast2_network_setup added
Actions #5

Updated by dheidler about 6 years ago

  • Assignee set to dheidler
Actions #6

Updated by dheidler about 6 years ago

  • Status changed from Workable to In Progress
Actions #7

Updated by dheidler about 6 years ago

  • Due date changed from 2018-10-23 to 2018-10-09
  • Target version changed from Milestone 20 to Milestone 19
Actions #8

Updated by dheidler about 6 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF