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(a)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 <alex(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/>
sbonazzo(a)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(a)ovirt.org
To unsubscribe send an email to users-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/users@ovirt.org/message/L2KTMHAJ7WL...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-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/users@ovirt.org/message/OW7YBSMFAYT...
--
真実はいつも一つ!/ Always, there's only one truth!