[ovirt-users] Re: [ovirt-devel] oVirt and Fedora

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...