action #50180
closed[functional][y] Make installation_overview page processing consistent (installation_overview and installation_overview_before are either unified or serve single purpose)
0%
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:
- Schedule it on all tests we run which install SLES
- Only schedule it in specific test-cases (I already saw some testsuite containing something like "+workaround_modules" on OSD)
- 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¶
- installation_overview and installation_overview_before are unified into single module or separated by functional load (one per module)
- 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