action #41429: [functional][y] test fails in yast2_network_setup - another case related to NM is the default network management - openQA Tests (public) - openSUSE Project Management Tool

Custom queries

All open Feature tests
openQA Infrastructure Project
openqa-review - Closed tickets last updated by openqa-review, last 30 days
QA roadmap long-term
QA SLE functional
QA SLE Functional - closed in last 14 days
QA SLE Functional - High, need to be refined
QA SLE Functional - over cycle time median
QA SLE u
QA SLE y
QA tools (tag not necessary in openQA and subprojects)
QA tools tag (tag not necessary in openQA and subprojects; excluding tickets in "Ready" version as they are already on the backlog)
QAC - Backlog
QAM
QE tools team - backlog (dev)
QE tools team - backlog (ready issues)
QE tools team - backlog SLA high
QE tools team - backlog SLA immediate
QE tools team - backlog SLA no immediate/urgent in feedback/blocked
QE tools team - backlog SLA normal
QE tools team - backlog SLA urgent
QE tools team - backlog SLO high
QE tools team - backlog SLO normal
QE tools team - backlog SLO urgent
QE tools team - backlog, high-level view (epics and higher)
QE tools team - backlog, non-reactive work, needs parent
QE tools team - backlog, top-level view (all sagas)
QE tools team - closed within last 14 days
QE tools team - closed within last 60 days
QE tools team - closed yesterday
QE Tools Team - Collaborative Session
QE tools team - due date forecast
QE tools team - exceeding due-date
QE tools team - infrastructure backlog
QE tools team - next - sorted by update time
QE tools team - next issues
QE tools team - non-estimated (unblocked) issues (dev)
QE tools team - non-estimated (unblocked) issues (infra)
QE tools team - ready issues - Workable
QE tools team - ready, not assigned/blocked/low
QE tools team - SLO high forecast
QE tools team - update forecast
QE tools team - updated by priority
QE tools team - what members of the team are working on - Feedback (not-low)
QE Tools Team Backlog By Assignee
SLE15 Migration Open Tickets
SLE15 SP1 Migration Open Tickets
SLE15SP3 Migration open ticket
SLE15SP3 Security open ticket
Tools Team Retrospective
Tools Team Retrospective (not estimated or assigned)

Actions

Copy link

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:

dheidler

Category:

Bugs in existing tests

Target version:

SUSE QA (private) - Milestone 19

Start date:

2018-09-21

Due date:

2018-10-09

% Done:

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 open — 3 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 issue

Resolved

riafarov

2018-08-21

2018-09-25

Actions

Related to openQA Tests (public) - action #40766: [functional][y] test fails in yast2_network_settings

Resolved

JERiveraMoya

2018-09-10

2018-09-25

Actions

Has duplicate openQA Tests (public) - action #41564: [functional][y] test fails in yast2_network_setup

Rejected

okurz

2018-09-25

2018-10-09

Actions

Issue # Delay: days Cancel

History
Notes
Property changes

Actions

Copy link

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

Copy link