If you'd prefer to keep going with CentOS Stream, there are a few options wrt QEMU:
- Getting a non-conflicting full build of QEMU in EPEL <https://docs.fedoraproject.org/en-US/epel/> - Rebuilding QEMU from CentOS Stream with the extra features enabled in the Virt SIG <https://wiki.centos.org/SpecialInterestGroup/Virtualization> - Rebuilding QEMU from CentOS Stream with the extra features enabled in the Hyperscale SIG <https://sigs.centos.org/hyperscale/> - Rebuilding QEMU from Fedora for CentOS Stream in a COPR <https://copr.fedorainfracloud.org/coprs/> But as far as supporting Fedora goes, it comes down to the following: - Porting Python and Java code to the newer versions as needed (which is required anyway to keep the project alive) - Ensuring vdsm uses FHS-compliant locations <https://bugzilla.redhat.com/show_bug.cgi?id=1260743> - Adapting for newer libvirt (mostly exposing new features) None of these are particularly huge efforts on their own, but they are things that take some low-grade effort continuously. Personally, I'd welcome supporting both Fedora and CentOS Stream. It hasn't happened in the past because there was a tug-of-war between RHV priorities and community priorities, but oVirt being primarily community driven opens up doors. On Fri, Jul 21, 2023 at 8:51 AM Jean-Louis Dupond via Users <users@ovirt.org> wrote: > Feel free to post patches to build oVirt on Fedora for example? What is > needed for it? Is it a big change? Can't we just support FC and CS if the > need is that high? > > The SPICE argument is a non-issue imo, there are already some people that > rebuild the qemu packages for CS9 with SPICE enabled, which will then just > work on oVirt afaik. > > Honestly, to me it looks like just another excuse to just not take things > into your own hands and start fixing things/work on the project. > Which I totally understand, but don't blame other things :) > > On 21/07/2023 08:43, Sandro Bonazzola wrote: > > > > Il giorno gio 20 lug 2023 alle ore 20:36 Alex McWhirter <a...@triadic.us> > ha scritto: > >> Largely package / feature support. RHEL is clearly betting the farm on >> OpenShift / OKD. Which is fine, but the decision to depreciate / remove >> things in RHEL (spice qxl, gluster) are also reflected in CentOS Stream. >> Even if you want to backport things to Stream as rebuilds of old / existing >> packages to re-enable some of those features you are now fighting a moving >> target. Would be easier to target RHEL than Stream if that is the goal. >> >> Fedora has no such depreciation of features, has a larger package >> library, and more room to grow oVirt into something more compelling. If the >> decision is made to base on CentOS Stream, might aa well base on Fedora >> instead as neither is going to have the full enterprise life cycle of RHEL >> and both will break things here and there. At least with Fedora you don't >> have to maintain an ever growing list of things to maintain to keep oVirt's >> feature set in tact. >> >> In short, targeting RHEL over Fedora made sense when CentOS existed as a >> downstream rebuild, when RHV was a product still, and when the entire oVirt >> feature set was supported by RHEL. None of those things are true today, and >> instead of targeting a psuedo RHEL where you still have to maintain a bunch >> of extra depreciated packages without the lifecycle commitment, Fedora >> makes more sense to me. >> >> My two cents anyways, for my use case not having Gluster or spice is a >> breaking change. While i wouldn't mind contributing to oVirt here and there >> as needed if someone picks up the pieces, i don't have the resources to >> also maintain the growing list of depreciated / cut features in the base OS. >> >> > Ok, I understand the point. > You may consider opening a poll and ask the user community if they would > prefer to have less features and stay on CentOS Stream and derivatives or > if they would prefer more features and move to Fedora. > If there's enough consensus around the move, you can try to gather some > interest around it and get some help pushing for this change. > > -- > > Sandro Bonazzola > > MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System > > Red Hat EMEA <https://www.redhat.com/> > > sbona...@redhat.com > <https://www.redhat.com/> > > *Red Hat respects your work life balance. Therefore there is no need to > answer this email out of your office hours. * > > > > _______________________________________________ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@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/users@ovirt.org/message/L2KTMHAJ7WL4EPC5JB47SJ6V2ZI3EDNZ/ > > _______________________________________________ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@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/users@ovirt.org/message/OW7YBSMFAYT2VOK34ROUXNOKXCO4DLMX/ > -- 真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/users@ovirt.org/message/5LO3YIOHPXJBVSV35IHSYFZRB5CDJHMT/
