Project

General

Profile

Actions
Copy link

action #50180

closed

[functional][y] Make installation_overview page processing consistent (installation_overview and installation_overview_before are either unified or serve single purpose)

Added by riafarov about 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
ybonatakis
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 25
Start date:
2018-06-28
Due date:
2019-06-04
% Done:

0%

Estimated time:
Difficulty:
hard

Description

Observation

We've a module called "installation_overview_before" which can - depending on set variables (e.g. WORKAROUND_DEPS or BREAK_DEPS) - handle broken dependencies while installing SLES.
In the most recent build of SP4 we noticed that this module is sometimes scheduled, sometimes not.
Also the already mentioned variables are set for some testsuites but not all of them.

An example of a functional test scheduling this module is:
https://openqa.suse.de/tests/latest?version=15-SP1&arch=x86_64&machine=64bit&test=allmodules%2Ballpatterns&flavor=Installer-DVD&distri=sle

Problem

How do we want to continue using this module? We should decide on one single solution. Current suggestions of mine would be:

  1. Schedule it on all tests we run which install SLES
  2. Only schedule it in specific test-cases (I already saw some testsuite containing something like "+workaround_modules" on OSD)
  3. Don't schedule it at all and remove the module if it is not needed/useful any longer (I somehow doubt that)

The question after all is, if we can use and apply the modules function (what does it actually do?) in a useful way for our automated tests.

Acceptance criteria

  1. installation_overview and installation_overview_before are unified into single module or separated by functional load (one per module)
  2. Name of the module reflects the purpose of the module

Additional info

I've set the difficulty of this to [hard] since there are maybe hundreds of tests using this module. Figuring out where it is needed, what it does and ultimately adjusting the module could have a big impact on automated testing.

Excerpt from IRC where this question was raised:

13:29 <nsinger> okurz: I wonder why we've a module for workarounding dep-issues but it is only active in "allpatterns"
13:29 <nsinger> okurz: is this by accident? Worth a poo to include this module in every installation?
13:30 <okurz> nsinger: yes please. I guess we should not try to answer this today because it needs a bit of "history lesson" before we can go further but IMHO we can improve -> please create ticket
13:31 <nsinger> okurz: that's why I asked. I knew there is some history I'm not aware of :D

Related issues 1 (0 open — 1 closed)

Copied from openQA Tests - action #37985: [functional][y][hard] Make installation_overview page processing consistent (installation_overview and installation_overview_before are either unified or serve single purpose)Resolvedybonatakis2018-06-282019-04-09

Actions
Actions
Copy link
 #1

Updated by riafarov about 5 years ago

  • Copied from action #37985: [functional][y][hard] Make installation_overview page processing consistent (installation_overview and installation_overview_before are either unified or serve single purpose) added
Actions
Copy link
 #3

Updated by riafarov about 5 years ago

What's about the jobs I've pointed you to when we checked where we have packages conflicts? Also, could you please run some test from staging just to be sure?

Actions
Copy link
 #4

Updated by ybonatakis about 5 years ago

one of them failed. which needed to be resolved. https://openqa.suse.de/tests/2799887#

Actions
Copy link
 #5

Updated by riafarov almost 5 years ago

  • Due date changed from 2019-04-23 to 2019-05-07
  • Status changed from In Progress to Feedback
Actions
Copy link
 #7

Updated by ybonatakis almost 5 years ago

the VR of the latest fix https://openqa.suse.de/tests/2821158

Actions
Copy link
 #9

Updated by JERiveraMoya almost 5 years ago

  • Due date changed from 2019-05-07 to 2019-05-21
  • Status changed from Feedback to In Progress

We are checking twice for the same variable, so we need to simplify this part according to @asmorodskyi. Moved to next sprint.

Actions
Copy link
 #10

Updated by mgriessmeier almost 5 years ago

  • Target version changed from Milestone 24 to Milestone 25

just moving to M25

Actions
Copy link
 #11

Updated by JERiveraMoya almost 5 years ago

We should move this ticket to feedback because there is a PR in review, right?

Actions
Copy link
 #12

Updated by ybonatakis almost 5 years ago

  • Status changed from In Progress to Feedback

PR been merged. Some VR needed

Actions
Copy link
 #13

Updated by JERiveraMoya almost 5 years ago

  • Due date changed from 2019-05-21 to 2019-06-04
Actions
Copy link
 #14

Updated by ybonatakis almost 5 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #15

Updated by tinawang123 almost 5 years ago

  • Status changed from Resolved to In Progress
Actions
Copy link
 #16

Updated by ybonatakis almost 5 years ago

  • Status changed from In Progress to Resolved
Actions
Copy link
 #17

Updated by okurz over 4 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: offline_sles15_scc_basesys+srv+phub_def_full
https://openqa.suse.de/tests/2910822

Actions
Copy link
 #18

Updated by okurz over 4 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: offline_sles15_scc_basesys+srv+phub_def_full
https://openqa.suse.de/tests/2910822

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed
Actions
Copy link
 #19

Updated by okurz over 4 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: offline_sles15_scc_basesys+srv+phub_def_full
https://openqa.suse.de/tests/2910822

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed
Actions
Copy link
 #20

Updated by okurz over 4 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: offline_sles15_scc_basesys+srv+phub_def_full
https://openqa.suse.de/tests/2910822

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed
Actions
Copy link
 #21

Updated by okurz over 4 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: offline_sles15_scc_basesys+srv+phub_def_full
https://openqa.suse.de/tests/2910822

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed
Actions
Copy link

Also available in: Atom PDF