action #33184
closed
[sle][functional][12sp4][u]test fails in docker - needs to add container module / how do we want to execute extra tests that rely on a registered image for SLE12?
Added by okurz about 6 years ago.
Updated over 4 years ago.
Description
Observation¶
openQA test in scenario sle-12-SP4-Server-DVD-x86_64-extra_tests_in_textmode@64bit fails in
docker
Reproducible¶
Fails since (at least) Build 0095
Suggestions¶
Further details¶
Always latest result in this scenario: latest
Reasoning for the current suggestions¶
The modules within SLE12 are developed and maintained separately from SLES using the maintenance process. Therefore we also use the module content of publically published repos and not any internal copy which is not developed in sync with any build of SLES anyway. Therefore we need to select a different approach than for SLE15 anyway. We already do that approach within "proxy_SCC+allmodules", e.g. for "puppet" or "salt" from ASMM. Publishing a "registered" image could mislead us to think that the module content would be consistent with the build of SLES12 but there is no hard relation between the both.
- Description updated (diff)
- Category changed from Bugs in existing tests to New test
- Subject changed from [sle][functional][12sp4]test fails in docker - needs to add container module to [sle][functional][12sp4]test fails in docker - needs to add container module / how do we want to execute extra tests that rely on a registered image for SLE12?
Need to discuss in a daily with the team to decide.
- Subject changed from [sle][functional][12sp4]test fails in docker - needs to add container module / how do we want to execute extra tests that rely on a registered image for SLE12? to [sle][functional][12sp4][u]test fails in docker - needs to add container module / how do we want to execute extra tests that rely on a registered image for SLE12?
Different options:
- O1: Just register the whole system and add the module for just one test module -> deregister again after the test module
- O2: Publish the hdd image from a test suite that registers the system and add a new test scenario like "extra_tests_registered" where we would schedule the docker module -> Con Quite different test flow for SLE12 vs. SLE15 as well as openSUSE
- O3: Manually add the one repo folder from openqa.suse.de -> Con Might not seem legit to everybody because we are not directly using the module as registered over SCC, Pro Easy way to not need another test suite and not mangle with registration
- Due date changed from 2018-04-10 to 2018-04-22
- Status changed from In Progress to Feedback
waiting for PR merged, should be not too much effort in next sprint.
PR merged but we should keep this ticket open and resolve the open points from the discussion on github:
czerw:
Please don't do it in this way. QAM tests have already container module added during installation.
See https://openqa.suse.de/tests/1604714 MRU_ADDONS=sdk,tcm,wsm,we,contm
So basically there is no need to add special repo for SLE12-SP3(not sure about SP4).
SergioAtSUSE:
@czerw, please be aware that the repo will only be added if package docker is not found. When container module is already added, the repo will not be
added. So it may work as expected.
But, I am still skeptical of this change. Now the reason why we need to add that repo is shadowed (to trick that we are using an image with
unregistered SUT. An scenario where the customer also could not install docker). This tricky added repo may affect the following test modules on this
test suite and people may forget about this and will probably understand/change this wrong. I would still prefer to use an image with registered SUT,
so we avoid false negatives and confusion.
- Due date deleted (
2018-04-22)
- Assignee deleted (
okurz)
- Target version changed from Milestone 15 to future
good to hear that, thank you. Next to the open point about "shouldn't we use repos over proxy scc for SLE12" I have one more open point which I also mentioned to pluskalm today: "Can we find a better long-term solution for tests that depend on the LTSS/non-LTSS state of the product" so that we do not have to update versions for tests like these just because a product goes into LTSS?
- Target version changed from future to future
- Status changed from Feedback to Workable
I suspect this in feedback ticket is going nowhere without an assignee.
- Status changed from Workable to Feedback
- Assignee set to SLindoMansilla
We should discuss the open points from #33184#note-9 first before we can continue.
I agree, I will take a look after the two urgent tickets, when I finish the one about journalctl.
- Description updated (diff)
- Status changed from Feedback to Workable
Should I create 2 new tickets for the tasks?
Is this ticket workable again?
- Parent task deleted (
#9466)
I don't understand the two new tasks you added. Why do you think we should create "registered" images?
Removing parent job and adding back as related as for now I think we can close the epic which was about "cover every module" and I think we do that well enough for installation as well as migration.
- Related to coordination #9466: [sle][functional][epic][medium][u]Modules - Containers: Test the SLE module for containers added
- Description updated (diff)
- Assignee deleted (
SLindoMansilla)
ok, fine. So basically what I proposed in #33184#note-6 . But, I discussed with SLindoMansilla in person and we found a new way, updated the description to use the "proxy_SCC+allmodules" scenario for SLE12 as the point where the test module should be executed.
- Priority changed from Normal to Low
let's focus more on improving our current tests and workflows first. Putting to "holding tank" :)
- Status changed from Workable to Rejected
Also available in: Atom
PDF