Il giorno lun 11 mag 2020 alle ore 09:35 Nir Soffer <nsoffer@redhat.com> ha scritto:
On Mon, May 11, 2020 at 10:01 AM Sandro Bonazzola <sbonazzo@redhat.com> wrote:


Il giorno lun 11 mag 2020 alle ore 08:50 Nir Soffer <nsoffer@redhat.com> ha scritto:
On Mon, May 11, 2020 at 9:16 AM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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. 

It's not really only about caring about Fedora. It's having capacity to work to make the code compatible with Fedora.
Either work on getting oVIrt stable and add features there or spend the same time fighting to get support for the code on Fedora.
Are you really ready to rebase your code to Python 3.9 (which already broke mom package) for Fedora 33 when we haven't yet full support for Fedora 30?
 
 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.

This is not true. We have CentOS Virtualization SIG, if you need a rebuild of libvirt and qemu from Fedora you can rebuild it there.
 

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.

If sanlock is not updated in CentOS Stream please open a bug for it.
If we can't get it on CentOS Stream we can still have it in CentOS Virt SIG.
 

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.

This just means we are not really supporting Fedora for the last 6.5 years. I don't see how it is different now.
We just made it clear we can't keep trying to keep the pace there.

 

What we should do instead is focus on Fedora support and testing early upstream packages.

This is an opensource project 99% developed by Red Hat and Red Hat developers have no capacity to keep working on Fedora support.
Nobody is going to block contributions for making oVirt working there.
We just can't commit ourselves to put effort there and tell users Fedora is supported being it completely untested and not having to time to fix stuff there even if somebody test it themselves.

 

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.

So what you are saying is we should focus on Fedora and stop supporting CentOS and RHEL.
Because we have no capacity for working on both and we can't support something we haven't tested.
 

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.

Not sure we can get advanced virtualization before it's released in RHEL but we can have upstream libvirt and qemu rebuilt from Fedora  or from upstream codebase.

 

Nir


--