Il giorno lun 11 mag 2020 alle ore 09:35 Nir Soffer <nsoffer(a)redhat.com> ha
scritto:
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.
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
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <
https://www.redhat.com/>
sbonazzo(a)redhat.com
<
https://www.redhat.com/>
[image: |Our code is open_] <
https://www.redhat.com/en/our-code-is-open>
*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<
https://mojo.redhat.com/docs/DOC-1199578>*