I changed the blivet swraid testcase (diff) due to our bios reduction changes. This one will remain blocking for bios, so I made it closer to Server docs. I didn't make it 1:1 (e.g. they use LVM on swraid), because I wanted to still keep it more of a generic testcase (blivet swraid testing, rather than very specific server use case testing). The actual blocking case is just the one specific in server docs, but we don't need to have exact specific test cases for everything listed in release criteria (that would be a lot of test cases). So, that was my thinking.
For OpenQA, it might be worth checking how you perform blivet swraid testing and perhaps make it also a bit closer to the server use case (or make it exactly the same, or make it two tests - that's up to you), e.g. by having biosboot on both disks, and having /boot also in swraid 1.
Metadata Update from @adamwill: - Custom field story_points adjusted to 3
Since this ticket is in our current sprint, but not assigned to anyone, I assume Adam took it, reflecting here and in Jira.
Metadata Update from @kparal: - Issue assigned to adamw
Metadata Update from @kparal: - Issue assigned to adamwill (was: adamw)
Reading through this, I noticed the changes you made to the test case don't account for all arches. "Create the required boot partitions needed for your architecture" is intentionally vague wording I use in a lot of test cases because it's very complex to describe all the requirements for all possible configurations (have fun reading the thousands of lines of anaconda that deal with it). A Power install needs a PReP boot partition, but not BIOS boot or ESP. God knows what s390x needs.
btw, do we also want to change the non-blivet test case in the same way?
A Power install needs a PReP boot partition, but not BIOS boot or ESP. God knows what s390x needs.
Right. But in this exact case, we have to know, because we need to say whether to create the partition on just one disk or both disks (which might possibly confuse firmware on alternative arches, I just don't know), and whether to have it as RAID or non-RAID partitions. I have no idea about any of this, and it felt like a waste of time to try to figure that out. The actual linked Server docs don't care about this either (they only mention BIOS and UEFI, which means x86 and Arm). And we have no PPC nor s390x anywhere in our test matrices. We run no such tests, we do no such test days... so while in theory it's nice to have a fully generic test case, and usually we can use a vague sentence to avoid actually figuring out the details :), in this case it requires us to do the work, while having no practical benefits. So I concentrated on the practical stuff, ignoring the rest. If you think adding "For other architectures, we have no idea, do something that seems correct" sentence in there feels better, I'm fine with that :)
No, we only block on Server+Blivet-GUI for this particular use case (criterion - see "BIOS mode exceptions"). Custom (non-blivet) can stay unchanged and completely general.
I just wanted this one to be a closer match for the actual blocking blocking use case for BIOS. But because this test case is also used for testing UEFI, I didn't want it to match the Server docs 100%, that felt like going too far in specificity. Definitely a matter of taste, though, we can adjust, if you feel differently.
I started work on this - it's on branch blivet-swraid-moar-raid - but the test failed on one config when I ran it, and I've not yet had time to get back to it.
blivet-swraid-moar-raid
OK, https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/445 passes on both UEFI and BIOS in my tests. It's a bit ugly, but meh.
PR merged.
Metadata Update from @adamwill: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/issues/417
Please continue any further discussion there.