openzfs
Promote 2.2.x to "stable" EL repos
Describe the feature would like to see added to OpenZFS
Provide 2.2.x packages for EL repos in the "stable" repo.
How will this feature improve OpenZFS?
Have 2.2.x features available on EL distros.
Additional context
Since 2.3.x is out and from what I can tell from various package-related issues, the 2.2.x branch is (or will be?) LTS and therefore suitable for EL. However, I couldn't find any "official" information about version promotion to EL so this is just an assumption.
My preference (which is only that, my preference :D) would be to wait until https://github.com/openzfs/zfs/discussions/17118 is resolved, AFAIK 2.1.x isn't affected. IMO some people (with heavier loaded boxes) would hit it fast, but we don't have a solution and it looks like it might take a bit to get to the bottom of it. Doing otherwise could IMO negatively impact OpenZFS reputation.
Enterprise Linux (RHEL, CentOS, and all the different clones... it used to also imply binary compatibility between those clones but I think it's now used more freely)
it used to also imply binary compatibility between those clones
It still does, to some extent. The alternatives are trying rather hard to achieve that, though it's not guaranteed these days afaik.
I blocked the 2.3 update from dnf to avoid it updating on all my servers for a few releases while the initial problems are resolved. With that said I do believe 2.2 should be marked stable soon.
Except it isn't stable :-D I mean, if random memory corruption isn't considered a problem, yeah, then ship it, here particularly, we're talking about a group of people who are expecting stability and have chosen OpenZFS because of its superior reputation... IMHO saying it's a risk would be a huge understatement...
In all fairness on the other hand, there are mmap corruption related patches, which didn't make it to 2.1.x... maybe there's just no ideal solution here for the moment.
We have historically bumped the major number when the EL zfs release got too old. For example, on RHEL8 we have provided RPMs for zfs-0.8.x, zfs-2.0.x, and zfs-2.1.x. Whether now is the right time to do that is still an open question. I don't have a very strong opinion on it one way or the other. Note that EL users can currently install from the zfs-testing repo if they want 2.2.x or 2.3.x branch.
I think the long-term solution is to provide version-specific repos: https://github.com/openzfs/zfs/discussions/17304. That way you could just say "I just want the zfs-2.2.x branch" or "I always want the newest zfs", etc.
Note that EL users can currently install from the zfs-testing repo if they want 2.2.x or 2.3.x branch.
True, but also:
These packages should not be used on production systems.
Then there's another problem - the testing repo contains 2.3.x but we don't want that, we want 2.2.x (for now) - that makes package management a bit more frustrating, especially at scale.
I agree that #17304 would probably be the best solution.
@tonyhutter Version specific repos is a really good idea, so users would be able to switch between legacy, old-stable and stable or such.
There's one detail that would need to be adressed IMO, when legagy (eg current 2.1 series) gets retired, running dnf update should inform the user that the repo does not exist anymore, so we can manually switch. Perhaps adding a "fake file" that needs old-stable (eg current 2.2 series) to legacy repo could do that trick, and the user would be informed without doing "behind it's back upgrades" from legacy to old-stable that could have production impacts.
In all fairness on the other hand, there are mmap corruption related patches, which didn't make it to 2.1.x... maybe there's just no ideal solution here for the moment.
I'm currently running into production problems since I moved my VMs from XFS to openzfs 2.1.16, but only for IO intensive KVM machines. I'm trying to solve the issue by changing my (tuned) qcow2 io mode from threads to native in hope it will reduce race conditions.
Indeed, I'm stuck with openzfs 2.1.16, and scared to update to 2.2.7 on my RHEL9 clones.
There's one detail that would need to be adressed IMO, when legagy (eg current 2.1 series) gets retired, running dnf update should inform the user that the repo does not exist anymore, so we can manually switch.
I believe that documenting deprecation in release notes is enough in this case. Bigger upstreams (like Rocky) do the same thing - a repo just vanishes when it's no longer supported and the user is expected to deal with it on their own and follow release notes, or else keep their own mirror if they have a need for older packages.
I totally understand the point brought up by @snajpa, for production you want to be able to choose a stable/LTS package. This is why I think that the solution proposed by @tonyhutter, makes sense - it allows the system admin to choose when to switch to another release/version on EL boxes.
2.2.8 is in the stable EL9 repos as of 12-Jun
Assuming that wasn't a whoopsie, seems like this issue can be closed
Great to hear that. I am still worried about the point @snajpa brought with issue mentioned in the first message.
