Hi Alex, > On 21. 11. 2022, at 19:56, Alex McWhirter <a...@triadic.us> wrote: > > I have some manpower im willing to throw at oVirt, but i somewhat need to > know if what the community wants and what we want are in line. >
I don't think anyone would oppose adding a new features. Removing is challenging, but we did went through quite a few removals too. Maintenance of all the various features has become a major burden to our team and things that were promising and useful can turn useless in few years and they need to be removed. > > 1. We'd bring back spice and maybe qxl. We are already maintaining forks of > the ovirt and RH kernels for this. We use ovirt currently for a lot of VDI > solutions paired with nvidia grid. Not usable over VNC. > SPICE has little development these days, and it's completely dropped from EL9. But other than that it's easy to keep in oVirt of course. > > 2. Hyperconverged storage is important. I'd suggest integrations with > linstor. Seems well aligned with ovirt. Bringing back gluster is likely the > wrong move. > We got decently far with managed storage using cinderlib. Repeating that with other implementation might be now easier, but it's still likely a big undertaking. Even teh cinderlib implementation is not really on par with the "native" vdsm storage code. > > 3. oVirt desperately needs vxlan support. Ideally integrating with FRR on the > backend so an ovirt node can just plug into an exiting EVPN VXLAN setup. > > 4. some things need cut from ovirt, namely hosted engine and maybe the > grafana stuff. Not that these aren't nice to have, but hosted engine rarely > actually works reliable in it's current state (compare mailing list > complaints of hosted engine vs other issues) and the grafana stuff can be > pushed into a sub project. > grafana is mostly its own thing, there's some common setup code but that's it. And TBH the most of the complexity around DWH and setup is the support for remote deployment...and that would indeed be the first thing to drop as something that doesn't bring any benefit anymore. It was originally introduced to reduce overload of ovirt-engine machine but over the time we got much more efficient and hw got so much better that it's not worth it anymore As for HE the problem is it's the most prevalent mode of deployment. It's complex, that's true, but mostly the deployment, not the "runtime". It's a lot of code and it's fair to consider dropping all of it, but OTOH we don't have any other high availability solution for engine host then. > > 5. It needs to do containers. Doesn't need to be the behemoth of OKD, but > something more along the lines of what k3s does, for now. > We had some experimental code in vdsm for container management from pre-kubernetes times. Ultimately it was removed in favor of doing it the other way around with Kubevirt. A simple management is probably not hard to add, but k8s features would probably require a full blown k8s distribution, even if "just" k3s and then you are again likely better off with adding Kubevirt to it. > > These are the thing's i'd like to see done, and maybe also cut back some of > the RHEL specific stuff to allow debian deployments (would massively help > with userbase). Basically for the past year i've been tasked with figuring > out if we are going to fork ovirt internally or move to OpenNebula. I prefer > the ovirt option if the opportunity now exists to take things in another > direction. > Rocky/Alma are almost there. Basically just the CI is missing and few small things here or there. Debian...we've tried that in early years, and besides limited capacity the major problem we had was with bugs. It's a mine field. We could influence RHEL to include the right fixes and depend on the right versions but with other distros it became too much to track. I guess it depends on resources, I think just switching to e.g. Debian wouldn't be too hard, there's no RHEL-specific code anywhere really. Overall I don't find any of the proposed directions problematic except for the Hosted Engine, that might need - at the very least - some transition plan. I believe a fresh blood in the project would be highly appreciated by everyone! Thanks, michal > > > On 2022-11-15 03:31, Sandro Bonazzola wrote: > >> >> >> Il giorno lun 14 nov 2022 alle ore 23:40 Frank Wall <f...@moov.de >> <mailto:f...@moov.de>> ha scritto: >> Hi Didi, >> >> thanks for keeping us updated. However, I'm concerned... >> >> > Ultimately, the future of oVirt lies in the hands of the community. If >> > you, as a community member, use and like oVirt, and want to see it >> > thrive, now is the best time to help with this! >> >> I don't want to be rude, but this sounds to me like no developers >> have shown interest in keeping oVirt alive. Is this true? Is no other >> company actively developing oVirt anymore? >> >> I've contacted directly all the companies with oVirt downstreams I was aware >> of. >> I also contacted almost all the universities that asked for help in this >> mailing list. >> I ended up contacting the major RHEL derivatives distributions. >> So far nobody stepped in to take an active role on the oVirt project. >> I saw some patches coming from individual contributors here and there but no >> company investment so far. >> >> >> >> > We worked hard over the last year or so on making sure the oVirt >> > project will be able to sustain development even without much >> > involvement from us - including moving most of the infrastructure from >> > private systems that were funded by/for oVirt/RHV, elsewhere - code >> > review from Gerrit to GitHub, and CI (Continuous Integration) from >> > jenkins to GitHub/Copr/CentOS CBS. >> >> I appreciate the effort to make the source code accessible. However, >> I'm also wondering: was any sort of governing organization established, >> so that development could actually take place when RedHat pulls the >> plug? >> >> Yes, oVirt has an open governance: >> https://www.ovirt.org/community/about/governance.html >> <https://www.ovirt.org/community/about/governance.html> >> Right now in the oVirt board other than Red Hat there's a member of the >> Caltech university https://www.ovirt.org/community/about/board.html >> <https://www.ovirt.org/community/about/board.html> >> >> >> The answer to this is probably related to my previous question, whether >> or not there are any non-RedHat developers involved. >> >> >> Ciao >> - Frank >> _______________________________________________ >> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> >> To unsubscribe send an email to users-le...@ovirt.org >> <mailto:users-le...@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/5DQ3OLT3B5QALLFUK4OMKDYJEJXSYP7A/ >> >> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/5DQ3OLT3B5QALLFUK4OMKDYJEJXSYP7A/> >> >> -- >> Sandro Bonazzola >> MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle OS >> Red Hat EMEA <https://www.redhat.com/> >> >> sbona...@redhat.com <mailto:sbona...@redhat.com> >> <blocked.gif> <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 <mailto:users@ovirt.org> >> To unsubscribe send an email to users-le...@ovirt.org >> <mailto:users-le...@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/IVCGZXVNOAFE44ASIH6UFZGURL3OUFRW/ >> >> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/IVCGZXVNOAFE44ASIH6UFZGURL3OUFRW/> > _______________________________________________ > 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/NV2TD2L4ZCKSLTG46VFNWDNHPZBHGNOC/
_______________________________________________ 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/E37HCOUJKJA42AGCPE5PTKOXWWYHQJIZ/
