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