[Criteria change proposal] Reduce the list of release-blocking storage interfaces during installation

Project Discussion
, , , ,
1

Hello folks,

we in Fedora Quality have wanted to re-evaluate the current list of release-blocking storage interfaces for some time now (here’s our ticket), and this proposal aims to do that. There are multiple reasons:

  1. We lost access to some advanced Server hardware that we used to perform testing on
  2. We lost a colleague who was doing all that work (thank you, Lili)
  3. It’s useful to go through the list from time to time anyway, to drop things which are very old, not used much anymore, or simply no longer that important

Please note: All the changes below only affect release-blocking status of that interface (i.e. whether a discovered bug is considered a blocker for the next release) - it doesn’t mean dropping support from Fedora, nor does it mean that bugs would no longer get fixed. All the listed changes affect the installer path only (we actually never had any storage interface criteria that would apply to the installed system).

The proposal summary

Make the following storage interfaces no longer release-blocking during the installation: PATA, SCSI (parallel SCSI), Firmware RAID, Hardware RAID, Fibre Channel, Fibre Channel over Ethernet (FCoE).

Note: The interfaces that would continue to be release-blocking during installation are the following: SATA, NVMe, SAS, iSCSI.

Justification

Most of these we can no longer test (PATA, parallel SCSI, HW RAID, Fibre Channel, FCoE). We can emulate PATA and SCSI in virtual machines, but they are just old interfaces.

For FW RAID, we still have one very old machine (Intel 4000 series, I believe) where we can test it. But the machine is very near its end of life. We have a brand new Ryzen 9000 machine with dual NVME SSDs, but the Linux kernel itself doesn’t support the type of FW RAID that’s in there. Keeping the old FW RAID types release-blocking when the moderns ones are not even functional seems pointless. Its actual real-world use also seems very limited.

SAS specifically was kept in the release-blocking list, because it seems widely used in Server scenarios. But we currently can’t test SAS either. We would have to rely on the Server WG for testing in this case, most probably.

Tell us what you think

We’re not experts on advanced storage interfaces. We’ve discussed some of this with the Server team prior to this proposal, but not all of it. Please tell us your opinion on how widespread and important the listed interfaces are.

Also note, there is a precedent where we could keep some of these interfaces still release-blocking, but also say we (Quality) won’t be required to test them. While possible, it can easily lead to inconvenient situations, like release-blocking bugs discovered by complete accident very shortly before the release date (or even after the release), because of the lack of regular testing. There should be a good reason for using this approach. We welcome your feedback on this.

Exact criteria changes

If implemented as currently proposed, the following release criteria changes would be performed:

  1. Change Basic_Release_Criteria#Storage_interfaces from:

‘Locally connected storage interfaces’ include PATA, SATA, NVMe, SAS, and SCSI.

to:

‘Locally connected storage interfaces’ include SATA, NVMe and SAS.

  1. Remove Fedora_45_Beta_Release_Criteria#Hardware_RAID completely.
  2. Remove Fedora_45_Final_Release_Criteria#Firmware_RAID completely.
  3. Change Fedora_45_Final_Release_Criteria#network-attached-storage from:

Supported network-attached storage types include iSCSI, Fibre Channel and Fibre Channel over Ethernet (FCoE).

to:

Supported network-attached storage types include iSCSI.

Feedback welcome.

//Edit: Implemented here.

8 Likes
2

While I do have a workstation that uses IMSM raid for it’s boot volume, dropping such testing by Fedora for release blockers seems to be entirely reasonable.

I don’t have any existing hardware (that I can still boot) with any of the other proposed storage interfaces, so I don’t have an strong thought there, but they too seem sufficiently rare to not require a full testing before release.

3

This all seems fine/reasonable to me.

As far as SAS goes, I think we might be able to repurpose some older sas using hardware in infrastructure for QE (or whoever) to test installs on. I would need to investigate more to see if thats going to work, but it’s possible.

4

This makes sense to me. If the Quality team can’t test it, then it shouldn’t be a blocker.

1 Like
6

Thanks for your feedback. Looping in also desktop teams for the purpose of a firmware raid (which might be a desktop use case somewhere).

If would also be great to see feedback from the Server or other potentially affected teams.

7

Since there was no further feedback, I’ll now go and implement the changes as proposed. Thanks everyone for participation!

8

The changes were now implemented:

Quality test cases and validation matrices will be adjusted accordingly.

Thanks everyone.

1 Like