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. -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@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 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
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. -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@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.*
Il giorno lun 11 mag 2020 alle ore 09:00 Sandro Bonazzola < sbonazzo@redhat.com> ha scritto:
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.
s/can/can't/ sorry for the typo
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@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.*
-- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@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>*
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. 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
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
-- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@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>*
On Mon, May 11, 2020 at 2: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.
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 <https://bugzilla.redhat.com/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!
On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, May 11, 2020 at 2: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.
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?
This was actually fixed a long time ago. With this commit: https://github.com/oVirt/vdsm/commit/67ba9c4bc860840d6e103fe604b16f494f60a09... 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 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@ovirt.org To unsubscribe send an email to devel-leave@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/JM5UNXG6YI7R23...
On Mon, May 11, 2020 at 8:32 AM Nir Soffer <nsoffer@redhat.com> wrote:
On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13@gmail.com> 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/67ba9c4bc860840d6e103fe604b16f494f60a09...
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!
On 11 May 2020, at 14:49, Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, May 11, 2020 at 8:32 AM Nir Soffer <nsoffer@redhat.com> wrote:
On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13@gmail.com> 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.
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/67ba9c4bc860840d6e103fe604b16f494f60a09...
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
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/SBAZ2F3FCOVGHR...
On Mon, May 11, 2020 at 11:45 AM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 11 May 2020, at 14:49, Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, May 11, 2020 at 8:32 AM Nir Soffer <nsoffer@redhat.com> wrote:
On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13@gmail.com> 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/67ba9c4bc860840d6e103fe604b16f494f60a09...
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... -- 真実はいつも一つ！/ Always, there's only one truth!
On 19 May 2020, at 14:06, Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, May 11, 2020 at 11:45 AM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 11 May 2020, at 14:49, Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, May 11, 2020 at 8:32 AM Nir Soffer <nsoffer@redhat.com> wrote:
On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13@gmail.com> 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.
the reason is mentioned in the original email, the lack of resources to keep actively supporting 3 different platforms. If you want to provide a helping hand and maintain Fedora infrastructure I don’t think anyone would object
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/67ba9c4bc860840d6e103fe604b16f494f60a09...
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...
it’s about capacity as well, it’s just a matter of someone writing a code which can handle the (long) transition period Thanks, michal
participants (4)
-
Michal Skrivanek -
Neal Gompa -
Nir Soffer -
Sandro Bonazzola