What is the status of the whole Ovirt Project?
Hello everybody, What is the status of the ovirt project, would be continued it in the Rocky Linunx9? the last message is so sad: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/HEKKBM6MZEKBEAX... Any good news/progress there? As a happy ovirt user since 2016 should we move to an another system? Thank you beforehand, Arman.
Hi Arman, the future of the oVirt project is in the hands of the community to be shaped. As Red Hat started the offboarding from the oVirt project about a year ago everyone saw the number of contributions lowering over the time. A good report about it is available here: https://cauldron.io/project/7653?from_date=2022-07-12&to_date=2023-07-12&tab=overview I tried to contact known downstreams and about 20 universities and research labs known to be using oVirt to some extent over the past 10 years asking if they were interested in getting engaged with the project and offering help with the onboarding process but nobody stepped in over the past 2 years. I also tried engaging with the Virtualization SIGs of the distributions compatible with oVirt but nothing happened so far in that direction as well. We had several people, groups and companies announcing their intention to contribute to the project at conferences and on mailing lists but no real commitment so far. So, the current status is: when someone in the community has a problem and the capacity to prepare a fix, they submit it (we had very good examples from https://github.com/dupondje ) and whenever someone find the time to review and merge the patches they get into oVirt master snapshot builds. So the general suggestion is to switch to oVirt master snapshot in order to get the system working on the latest el8 / el9 as the last stable release is already known to have troubles. The project is not dead but it's for sure in a very low maintenance mode until someone will invest in its development. Il giorno mer 12 lug 2023 alle ore 13:24 Arman Khalatyan <arm2arm@gmail.com> ha scritto:
Hello everybody, What is the status of the ovirt project, would be continued it in the Rocky Linunx9? the last message is so sad: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/HEKKBM6MZEKBEAX...
Any good news/progress there?
As a happy ovirt user since 2016 should we move to an another system?
Thank you beforehand, Arman. _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-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/users@ovirt.org/message/6Z5CCSNZPSBBG2...
-- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System Red Hat EMEA <https://www.redhat.com/> sbonazzo@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.*
I am beginning to have very similar thoughts. It's working fine for me now, but at some point something big is going to break. I already have VMWare running, and in fact, my two ESXi nodes have the exact same hardware as my two KVM nodes. Would be simple to do, but I really don't want to go just yet. At the same time, I don't want to be the last person turning off the lights. Difficult times.
We still have a few oVirt and RHV installs kicking around, but between this and some core features we use being removed from el8/9 (gluster, spice / qxl, and probably others soon at this rate) we've heavily been shifting gears away from both Red Hat and oVirt. Not to mention the recent drama... In the past we toyed around with the idea of helping maintain oVirt, but with the list of things we'd need to support growing beyond oVirt and into other bits as well, we aren't equipped to fight on multiple fronts so to speak. For the moment we've found a home with SUSE / Apache CloudStack, and when el7 EOL's that's likely going to be our entire stack moving forward. On 2023-07-13 02:21, eshwayri@gmail.com wrote:
I am beginning to have very similar thoughts. It's working fine for me now, but at some point something big is going to break. I already have VMWare running, and in fact, my two ESXi nodes have the exact same hardware as my two KVM nodes. Would be simple to do, but I really don't want to go just yet. At the same time, I don't want to be the last person turning off the lights. Difficult times. _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-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/users@ovirt.org/message/EJFIRAT6TNCS5T...
Hi, We switched from Gluster to NFS provided by SAN array: maybe it was matter of combination of factors (configuration/version/whatever), but it was unstable for us. SPICE/QXL in RHEL 9: yeah, I understand that for some people it is important (I saw that someone is doing some forks whatever) I think that ovirt 4.5 (nightly build __) might be OK for some time, but I think that alternatives are: -OpenStack for larger setups (but be careful with distribution -as I remember Red Hat abandons TripleO and introduces OpenShift stuff for installation of OpenStack) -ProxMox and CloudStack for all sizes. -Maybe XCP-ng + (paid?) XenOrchestra, but I trust KVM/QEMU more than Xen __ OpenShift Virtualization/OKD Virtualization - I don't know... Actually might be good if someone specifically comments on going from ovirt to OpenShift Virtualization/OKD Virtualization. Not sure if this statement below https://news.ycombinator.com/item?id=32832999 is still correct and what exactly are the consequences of 'OpenShift Virtualization is just to give a path/time to migrate to containers' "The whole purpose behind OpenShift Virtualization is to aid in organization modernization as a way to consolidate workloads onto a single platform while giving app dev time to migrate their work to containers and microservice based deployments." BR, Konstantin Am 13.07.23, 09:10 schrieb "Alex McWhirter" <alex@triadic.us <mailto:alex@triadic.us>>: We still have a few oVirt and RHV installs kicking around, but between this and some core features we use being removed from el8/9 (gluster, spice / qxl, and probably others soon at this rate) we've heavily been shifting gears away from both Red Hat and oVirt. Not to mention the recent drama... In the past we toyed around with the idea of helping maintain oVirt, but with the list of things we'd need to support growing beyond oVirt and into other bits as well, we aren't equipped to fight on multiple fronts so to speak. For the moment we've found a home with SUSE / Apache CloudStack, and when el7 EOL's that's likely going to be our entire stack moving forward. On 2023-07-13 02:21, eshwayri@gmail.com <mailto:eshwayri@gmail.com> wrote:
I am beginning to have very similar thoughts. It's working fine for me now, but at some point something big is going to break. I already have VMWare running, and in fact, my two ESXi nodes have the exact same hardware as my two KVM nodes. Would be simple to do, but I really don't want to go just yet. At the same time, I don't want to be the last person turning off the lights. Difficult times. _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/EJFIRAT6TNCS5T... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/EJFIRAT6TNCS5TZUFPGBV5UZSCBW6LE4/>
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/EFBHZ76GZ73HA5... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/EFBHZ76GZ73HA52XJMGTRGTYCPIGNPHH/>
I would personally put CloudStack in the same category as OpenStack. Really the only difference is monolithic vs micro services. Both scale quite well regardless, just different designs. People can weigh the pros and cons of either to figure out what suites them. CloudStack is certainly an easier thing to wrap your head around initially. There is also OpenNebula, similar to CloudStack in design. However their upgrade tool is closed source, so i can't recommend them as much as i would like to as i think they have a decent product otherwise. ProxMox currently doesn't work as an oVirt replacement for us as it cannot scale beyond a single cluster and has limited multi tenancy support. I hear they have plans for multi cluster at some point, but currently i regard it as more akin to ESXi without vSphere. Where oVirt i would have compared closer to ESXi with vSphere. I think XCP-ng has a bright future at the rate they are going, just doesn't currently supply all the features of oVirt. OKD (OpenShift) virtualization is more or less just kubevirt. If all you need vm's for is a few server instances, works well enough. Feature wise it's not comparable to everything above, but if you can live with your vm's being treated more or less like containers workflow / life cycle wise and don't need much more then that, it probably gets the job done. Harvester is another consideration if you think the OKD solution will work, but don't like the complexity. It's based on k3s, provides kubevirt, and is a much more simple install. I think they even provide an ISO installer. Reality is, there is no great oVirt replacement so to speak. If you only needed oVirt to manage a single cluster, ProxMox probably fits the bill. XCP-ng as well if you are willing to do some leg work. Otherwise closest FOSS thing i have found (spent over a year evaluating) is CloudStack. I am still hopeful someone will step up to maintain oVirt (Oracle?), but it's clear to me at this point it will need rebased onto Fedora or something else to keep it's feature set fully alive. On 2023-07-13 11:10, Volenbovskyi, Konstantin via Users wrote:
Hi, We switched from Gluster to NFS provided by SAN array: maybe it was matter of combination of factors (configuration/version/whatever), but it was unstable for us. SPICE/QXL in RHEL 9: yeah, I understand that for some people it is important (I saw that someone is doing some forks whatever)
I think that ovirt 4.5 (nightly build __) might be OK for some time, but I think that alternatives are: -OpenStack for larger setups (but be careful with distribution -as I remember Red Hat abandons TripleO and introduces OpenShift stuff for installation of OpenStack) -ProxMox and CloudStack for all sizes. -Maybe XCP-ng + (paid?) XenOrchestra, but I trust KVM/QEMU more than Xen __ OpenShift Virtualization/OKD Virtualization - I don't know... Actually might be good if someone specifically comments on going from ovirt to OpenShift Virtualization/OKD Virtualization.
Not sure if this statement below https://news.ycombinator.com/item?id=32832999 is still correct and what exactly are the consequences of 'OpenShift Virtualization is just to give a path/time to migrate to containers' "The whole purpose behind OpenShift Virtualization is to aid in organization modernization as a way to consolidate workloads onto a single platform while giving app dev time to migrate their work to containers and microservice based deployments."
BR, Konstantin
Am 13.07.23, 09:10 schrieb "Alex McWhirter" <alex@triadic.us <mailto:alex@triadic.us>>:
We still have a few oVirt and RHV installs kicking around, but between this and some core features we use being removed from el8/9 (gluster, spice / qxl, and probably others soon at this rate) we've heavily been shifting gears away from both Red Hat and oVirt. Not to mention the recent drama...
In the past we toyed around with the idea of helping maintain oVirt, but with the list of things we'd need to support growing beyond oVirt and into other bits as well, we aren't equipped to fight on multiple fronts so to speak.
For the moment we've found a home with SUSE / Apache CloudStack, and when el7 EOL's that's likely going to be our entire stack moving forward.
On 2023-07-13 02:21, eshwayri@gmail.com <mailto:eshwayri@gmail.com> wrote:
I am beginning to have very similar thoughts. It's working fine for me now, but at some point something big is going to break. I already have VMWare running, and in fact, my two ESXi nodes have the exact same hardware as my two KVM nodes. Would be simple to do, but I really don't want to go just yet. At the same time, I don't want to be the last person turning off the lights. Difficult times. _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/EJFIRAT6TNCS5T... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/EJFIRAT6TNCS5TZUFPGBV5UZSCBW6LE4/>
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/EFBHZ76GZ73HA5... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/EFBHZ76GZ73HA52XJMGTRGTYCPIGNPHH/>
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-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/users@ovirt.org/message/O6KPWG3HA6IJY2...
Il giorno ven 14 lug 2023 alle ore 00:07 Alex McWhirter <alex@triadic.us> ha scritto:
I would personally put CloudStack in the same category as OpenStack. Really the only difference is monolithic vs micro services. Both scale quite well regardless, just different designs. People can weigh the pros and cons of either to figure out what suites them. CloudStack is certainly an easier thing to wrap your head around initially.
[cut]
Otherwise closest FOSS thing i have found (spent over a year evaluating) is CloudStack. I am still hopeful someone will step up to maintain oVirt (Oracle?), but it's clear to me at this point it will need rebased onto Fedora or something else to keep it's feature set fully alive.
I'm curious, why do you think Fedora rebase is necessary to keep oVirt alive? We tried that for years and gave up as Fedora is moving way too fast to keep oVirt aligned with the changes. CentOS Stream 9 has EOL is estimated to be 2027 according to https://centos.org/stream9/ and I expect CentOS Stream 10 to show up by the end of this summer according to https://www.phoronix.com/news/CentOS-Stream-10-Start (well, official GA will be in a year but I guess people can start playing with it much earlier). -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System Red Hat EMEA <https://www.redhat.com/> sbonazzo@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.*
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. On 2023-07-14 02:27, Sandro Bonazzola wrote:
Il giorno ven 14 lug 2023 alle ore 00:07 Alex McWhirter <alex@triadic.us> ha scritto:
I would personally put CloudStack in the same category as OpenStack. Really the only difference is monolithic vs micro services. Both scale quite well regardless, just different designs. People can weigh the pros and cons of either to figure out what suites them. CloudStack is certainly an easier thing to wrap your head around initially.
[cut]
Otherwise closest FOSS thing i have found (spent over a year evaluating) is CloudStack. I am still hopeful someone will step up to maintain oVirt (Oracle?), but it's clear to me at this point it will need rebased onto Fedora or something else to keep it's feature set fully alive.
I'm curious, why do you think Fedora rebase is necessary to keep oVirt alive? We tried that for years and gave up as Fedora is moving way too fast to keep oVirt aligned with the changes. CentOS Stream 9 has EOL is estimated to be 2027 according to https://centos.org/stream9/ and I expect CentOS Stream 10 to show up by the end of this summer according to https://www.phoronix.com/news/CentOS-Stream-10-Start (well, official GA will be in a year but I guess people can start playing with it much earlier).
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System
Red Hat EMEA [1]
sbonazzo@redhat.com
[1]
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-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/users@ovirt.org/message/NTLNZVCFU525GK...
Links: ------ [1] https://www.redhat.com/
Il giorno gio 20 lug 2023 alle ore 20:36 Alex McWhirter <alex@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@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.*
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@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@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 tousers-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/users@ovirt.org/message/L2KTMHAJ7WL4EP...
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 <alex@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@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-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/users@ovirt.org/message/L2KTMHAJ7WL4EP...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-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/users@ovirt.org/message/OW7YBSMFAYT2VO...
-- 真実はいつも一つ！/ Always, there's only one truth!
All, I'd rather base against either Rocky or Alma in the shorter term, or Ubuntu/Debian for a longer view. oVirt IMHO is a superior product to anything else if you know your way around it. Fantastic and informative GUI, a great set of APIs, and pretty solid in terms of storage support. I'm running it hyperconverged over ZFS+DRBD with Corosync and Pacecmaker in a 2 node cluster. I'm currently running a cluster on Rocky 8 and it's working perfectly at the moment. I'm not a fan of Gluster for its small I/O performance but I'm sure it's still a useful option for running VMs with heavy storage requirements with lesser small I/O performance requirements. Fedora would get you fired from a lot of SME or enterprise environments. And with the mess around IBM/RH who knows if they'll drop OpenShift next and pull the devs out of OKD?
On Thu, Sep 7, 2023 at 8:35 AM Alex Crow via Users <users@ovirt.org> wrote:
All,
I'd rather base against either Rocky or Alma in the shorter term, or Ubuntu/Debian for a longer view. oVirt IMHO is a superior product to anything else if you know your way around it. Fantastic and informative GUI, a great set of APIs, and pretty solid in terms of storage support. I'm running it hyperconverged over ZFS+DRBD with Corosync and Pacecmaker in a 2 node cluster.
Basing on CentOS Stream means we should work just fine on AlmaLinux easily enough. From a platform expansion perspective, the easiest would be to add SUSE distributions. We can reuse most of our infrastructure today to build for openSUSE, since it's largely compatible with our existing platforms.
I'm currently running a cluster on Rocky 8 and it's working perfectly at the moment. I'm not a fan of Gluster for its small I/O performance but I'm sure it's still a useful option for running VMs with heavy storage requirements with lesser small I/O performance requirements.
Fedora would get you fired from a lot of SME or enterprise environments. And with the mess around IBM/RH who knows if they'll drop OpenShift next and pull the devs out of OKD?
I think you'd be surprised how many people use Fedora in a business production environment. With the right automation and management, Fedora is an easy platform to work with. As for dropping OpenShift and pulling out of OKD, that would be ludicrous. It's their moneymaker right now: https://www.linkedin.com/posts/red-hat_congrats-to-the-openshift-team-on-hit... -- 真実はいつも一つ！/ Always, there's only one truth!
Thanks Neal, your insight is very much appreciated. A lot of people forget about SuSE, but it's got the same ethos that RH had a few years ago, and it's worth looking into. I can imagine Fedora being a choice in CI/CD deployments but I'd be surprised is more old-fashioned companies would accept the risk. Going through a whole risk vs cost thing right now. It does seem that OpenShift is a potent platform, and pulling out of OKD would be a horrible mess, so here's hoping that if oVirt dies that OKD is a viable platform for both containers and Virtualisation (ah, legacy workloads!). It's just a shame that oVirt no longer has the sponsorship, I've been relentlessly ragged on on Reddit for admitting to using it (mostly from Hyper-V fanbois), but it's far, far better than Hyper-V and much less restrictive than VMWare. Hyper-V had me pulling my remaining hair out almost every single day. Five clicks to get the MAC address of a VM? Dynamic MAC addresses not being cluster-wide and pinned to a VM, so they change after a migration? Yuck. I will read that link now! Best regards Alex
Just out of curiosity how's the live migration in oVirt hyperconverged? Last I heard that didn't work well if at all. ZFS+DRBD is awesome, I had also read these don't work well together, so that's two things that surprised me reading this. 😊 There is a migration path to OLVM, if you can stand Oracle. I also considered OKD, but totally agree with the sentiment we have no idea what Red Hat are gunna pull out of next but it doesn't look good ☹ -----Original Message----- From: Alex Crow via Users <users@ovirt.org> Sent: Saturday, September 2, 2023 4:09 PM To: users@ovirt.org Subject: [ovirt-users] Re: What is the status of the whole Ovirt Project? All, I'd rather base against either Rocky or Alma in the shorter term, or Ubuntu/Debian for a longer view. oVirt IMHO is a superior product to anything else if you know your way around it. Fantastic and informative GUI, a great set of APIs, and pretty solid in terms of storage support. I'm running it hyperconverged over ZFS+DRBD with Corosync and Pacecmaker in a 2 node cluster. I'm currently running a cluster on Rocky 8 and it's working perfectly at the moment. I'm not a fan of Gluster for its small I/O performance but I'm sure it's still a useful option for running VMs with heavy storage requirements with lesser small I/O performance requirements. Fedora would get you fired from a lot of SME or enterprise environments. And with the mess around IBM/RH who knows if they'll drop OpenShift next and pull the devs out of OKD? _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-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/users@ovirt.org/message/FVSMQSPYXWJC3E...
participants (9)
-
Alex Crow -
Alex McWhirter -
Arman Khalatyan -
Christopher Law -
eshwayri＠gmail.com -
Jean-Louis Dupond -
Neal Gompa -
Sandro Bonazzola -
Volenbovskyi, Konstantin