Plan what to do about advanced storage testing #889
Labels
No labels
agile
anacondawebui
arm
blockerfe
Closed As
Duplicate
Closed As
Fixed
Closed As
Invalid
Closed As
Wontfix
Closed As
Worksforme
coreos
criteria
defect
easyfix
enhancement
iot
meeting
meta
onboarding call
proventesters
retrospective
silverblue
sponsor
test cases
test days
wiki
ai-review-please
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
pr2jira
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Blocks
#4 Fedora 45 release tracking
cle/tickets
Reference
quality/tickets#889
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Since lili is no longer available, we need someone else to own https://forge.fedoraproject.org/quality/fedora-release-autotest and the exotic storage hardware testing that was still(?) done using it. It was forked off fedora_openqa and hacked up to create jobs in Beaker, basically. So we need to find someone to initiate whoever the lucky winner is into the mysteries of Beaker. Would be nice if we can clean it up a bit and get result reporting done automatically, too.
First I think we need to figure out the status of the tool. Was is really used? For what exactly? Was Lili's exotic hw testing really done through this?
Lili said the project is still active, and that's why we migrated it. But codebase was basically frozen for the last 4 years, and I'm quite skeptical that something that was used regularly didn't need any maintenance. Also, I can't find any actual test cases in that project, just their metadata descriptions. If this is used for say FCOE testing, where is the testcase code?
Once we figure this out, we should discuss whether we actually want to maintain this. And then designate the maintainer 🙂
(And for the almost-done F44 cycle, we should contact Server SIG and ask them to test that exotic hw in their team).
I can look into this one.
Firstly I would like to check which hw were used and which hw are still available for us.
Some of the beaker jobs could be replaced by testing-farm which is now more supported.
I think the 'tests' are really just kickstarts - after all, all we're establishing here is "does the installer work with this weird storage hardware?", so all we need to do is run a kickstart install on appropriately-configured hardware. Note that https://forge.fedoraproject.org/quality/fedora-release-autotest/src/branch/master/fedora_release_autotest/conf_test_cases.py has a bunch of
ks_appendvalues in it which are probably significant. I suspect Lili might have been doing post-install validation and reporting results manually, since I think beaker allows interactive access to the configured hardware.My theory is that all this does, in the end, is generate appropriate kickstarts and beaker requests for the appropriate hardware and then plug Kickstart A into Beaker Hardware B.
As for the lack of maintenance - well, we haven't changed the tests in forever, and I don't think Beaker changes much, I think RH has it filed under "annoying old thing we haven't figured out how to get rid of yet". So I think it's kinda plausible this could keep working without much change.
We can ask if they want to, but let's be careful not to cast this as requiring them to do it - IIRC, all these exotic storage requirements have been around forever and didn't originate with the Server WG (I think they pre-date it).
If we can't figure this out quickly it might be reasonable for F44 to just not complete this testing and flag up that we were unable to do it due to the situation.
So, update here: we now know how to run tests in beaker in theory (right @psklenar ?), but we don't have access to the specific hardware the matrix wants us to test on, due to...Red Hat stuff.
So, before Fedora 45 Beta, we have to I guess either:
Thoughts?
Removing this from current sprint as we released F44 with a kinda waiver for this so it's no longer super urgent, we have a bit of time to think it through.
Find new maintainer for fedora-release-autotest, onboard to mysteries of beaker etc.to Plan what to do about advanced storage testing#890 is related to this
@adamwill wrote in #889 (comment):
yes
I am going to ask 'server workgroup' about #890 what is really required. And then let's see what we can run with the current and free hw.