If you have followed the oVirt project for a few releases you already know oVirt has struggled to keep the pace with the fast innovation cycles Fedora Project is following.
Back in September 2019 CentOS project launched CentOS Stream as a rolling preview of future RHEL kernels and features, providing an upstream development platform for ecosystem developers that sits between Fedora and RHEL.
Since then the oVirt project tried to keep the software working on Fedora, CenOS Stream, and RHEL/CentOS but it became quickly evident the project lacked resources to keep the project running on three platforms. Further, our user surveys show that oVirt users strongly prefer using oVirt on CentOS and RHEL.
With the upcoming end of life of Fedora 30 the oVirt project has decided to stop trying to keep the pace with this amazing platform, focusing on stabilizing the software codebase on RHEL / CentOS Linux. By focusing our resources and community efforts on RHEL/CentOS Linux and Centos Stream, we can provide better support for those platforms and use more time for moving oVirt forward.
Where was this discussed?
There is nothing about this in
devel@ovirt.org or any other public mailing list.
I think this is a big mistake. It will mainly harm development since Fedora is the only platform where
we can test early upstream changes, many months (and sometimes years) before the packages reach
RHEL/CentOS.
Nir
It has been discussed within team leads meeting and made clear by replies we keep giving when someone ask about Fedora.
See "[ovirt-users] install oVirt on Fedora31", "[ovirt-users] oVirt orb python3/fedora 31 support".
This doesn't mean that individual developers can try to get their packages working on Fedora or test their code on Fedora.
This means that we are not committed to keep trying to support Fedora as a project.
Again, there was no discussion about this in public, but we can start the discussion here.
The result of such a change is that soon there will be no way to install vdsm on Fedora,
because we need only one maintainer that does not care about Fedora.
Then we cannot test vdsm with upstream libvirt and qemu, which will harm our ability to develop
features like incremental backup, which was developed in the last year on Fedora, using upstream
libvirt and qemu or upstream patches.
Another example, if you want to test sanlock fixes that will be available in RHEL 8.3, the only way
to do this now is on Fedora - the fixes are available in updates-testing. So we can make sure our
code is compatible with new sanlock now, or wait until 8.3 is out and find about regressions
very late before the release.
This is a common trend in the last 6.5 years - oVirt is not tested on Fedora (e.g. no ovirt
systems on Fedora), leading to late detection of issues, and regressions in new versions
in RHEL/CentOS.
What we should do instead is focus on Fedora support and testing early upstream packages.
Currently oVirt is tested on CentOS 8.1, which is irrelevant to oVirt 4.4. What we really need
is to test on RHEL 8.2 nightly builds, but this is not available to the public and cannot be
used by an upstream project. But Fedora 32 is available and includes all the packages
needed for valuable testing, so this should be our main platform for testing.
CentOS stream could be a good solution for testing, if we could get the advanced virt module
*before* the module is released in RHEL. Otherwise we test on old version and we don't detect
issues in time.
Nir