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.

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

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

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

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

On Mon, May 11, 2020 at 2:16 AM Sandro Bonazzola <sbonazzo(a)redhat.com&gt; 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. > This is a humongous mistake. Almost everything with virtualization and storage starts in Fedora. And there are some configurations that will not be possible in CentOS Stream because of the nature of it. As far as the oVirt software keeping up with Fedora, the main problem here has always been that people aren't integrating their software into the distribution itself. That's how everything can get tested together. And this comes back to the old bug about fixing vdsm so that it doesn't use /rhev, but instead something FHS-compliant (RHBZ#1369102). Once that is resolved, pretty much the entire stack can go into Fedora. And then you benefit from the Fedora community being able to use, test, and contribute to the oVirt project. As it stands, why would anyone do this for you when you don't even run on the cutting edge platform that feeds into Red Hat Enterprise Linux?

It also seems like the oVirt folks are not learning from the mistakes of the RDO project. They gave up on Fedora several years ago, and wound up spending close to two years playing catchup on Python 3, DNF, modularity, virtualization packaging changes, storage APIs, and everything else all at once. They ground to a halt. They paid a price for not keeping up. And their excuse of unaligned lifecycles stopped being true more than two years ago, when OpenStack's release cycles aligned on Fedora's again. They also proved that Fedora's "churn" wasn't the problem because when push comes to shove, they were able to do something based on Fedora 28 (knowing it was the base for RHEL 8). CentOS Stream is worthless in most respects because you aren't really testing or integrating anything new most of the time, you're just making new releases of your software on a stale platform. Again, the purpose of CentOS Stream is to provide a window into the RHEL stream development, which by the nature of things isn't very useful for future-proofing. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JM5UNXG6YI7...

On 11 May 2020, at 14:49, Neal Gompa <ngompa13(a)gmail.com&gt; wrote: On Mon, May 11, 2020 at 8:32 AM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > > On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: >> >> As far as the oVirt software keeping up with Fedora, the main problem here has always been that people aren't integrating their software into the distribution itself.

>> That's how everything can get tested together. And this comes back to the old bug about fixing vdsm so that it doesn't use /rhev, but instead something FHS-compliant (RHBZ#1369102). Once that is resolved, pretty much the entire stack can go into Fedora. And then you benefit from the Fedora community being able to use, test, and contribute to the oVirt project. As it stands, why would anyone do this for you when you don't even run on the cutting edge platform that feeds into Red Hat Enterprise Linux? > > This was actually fixed a long time ago. With this commit: > https://github.com/oVirt/vdsm/commit/67ba9c4bc860840d6e103fe604b16f494f60... > > You can configure a compatible vdsm that does not use /rhev. > > Of course it is not backward compatible, for this we need much more > work to support live migration > between old and new vdsm using different data-center configurations. > It'd probably be simpler to just *change* it to an FHS-compatible path going forward with EL8 and Fedora and set up a migration path there, but it's a bit late for that... :(

-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/SBAZ2F3FCOV...

On 19 May 2020, at 14:06, Neal Gompa <ngompa13(a)gmail.com&gt; wrote: On Mon, May 11, 2020 at 11:45 AM Michal Skrivanek <michal.skrivanek(a)redhat.com&gt; wrote: > > > >> On 11 May 2020, at 14:49, Neal Gompa <ngompa13(a)gmail.com&gt; wrote: >> >> On Mon, May 11, 2020 at 8:32 AM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: >>> >>> On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: >>>> >>>> As far as the oVirt software keeping up with Fedora, the main problem here has always been that people aren't integrating their software into the distribution itself. > > it was never a good fit for oVirt to be part of other distributions. We had individual packages part of Fedora in history, but there are things which are hard to accept (like automatically enabling of installed services, UIDs), and overall it’s just too complex, we’re rather a distribution than a simple app on top of base OS. > None of those things are hard to do in Fedora. They're incredibly easy to do. I know this because I've gone through this process already before. But fine, let's assume I consider this argument valid. Then there's still no reason not to be continually providing support for Fedora as an add-on, as you have before.

>>>> That's how everything can get tested together. And this comes back to the old bug about fixing vdsm so that it doesn't use /rhev, but instead something FHS-compliant (RHBZ#1369102). Once that is resolved, pretty much the entire stack can go into Fedora. And then you benefit from the Fedora community being able to use, test, and contribute to the oVirt project. As it stands, why would anyone do this for you when you don't even run on the cutting edge platform that feeds into Red Hat Enterprise Linux? >>> >>> This was actually fixed a long time ago. With this commit: >>> https://github.com/oVirt/vdsm/commit/67ba9c4bc860840d6e103fe604b16f494f60... >>> >>> You can configure a compatible vdsm that does not use /rhev. >>> >>> Of course it is not backward compatible, for this we need much more >>> work to support live migration >>> between old and new vdsm using different data-center configurations. >>> >> >> It'd probably be simpler to just *change* it to an FHS-compatible path >> going forward with EL8 and Fedora and set up a migration path there, >> but it's a bit late for that... :( > > It wouldn’t. We always support live migration across several versions (now it’s 4.2-4.4) and it needs to stay the same or youo have to go with arcane code to mangle it back and forth which gets a bit ugly when you consider suspend/resume, snapshots, etc > Erk. At some point you need to bite the bullet though...