[ovirt-users] Re: Alternative Perspective - Re: oVirt alternatives

I wouldn't mind doing some testing. I have a little coding experience but it's mostly on the desktop (Application) side of things not Web. Although if it meant getting a proper certificate management UI I'd be willing do it. (I've been thinking about rolling up my sleeves for that exact purpose anyway.) The main issue as I see it is two fold: 1. We don't have all of the needed sources to rebuild ovirt from scratch. I.e. We're missing the oVirt Node build scripts. Further, we also don't have a complete set of SRPMs. I've tried getting them for backup / disaster recovery issues, and it's a huge pain to track them all down from the various repos that are involved. Keep in mind that was *before* RH started archiving repos so it's probably even harder now. (Note: You can't just do "reposync -- source" that's been broken for years because CentOS didn't want to rebuild their package lists to include them automaticly. Some of them are on vault.centos.org, but some are not. Tracking down the third party repos oVirt uses is also difficult for the same reason.) Does anyone have a link to the complete set of source packages outside of oVirt's dev team?         2. oVirt's fate is still very much uncertain. I don't think anyone really wants to go through the trouble of creating a fork unless oVirt as a project is truely EOL'd. Currently we know that RHVM will EOL in a few years, but the oVirt project itself has made no such annoucement. All of the threads on this subject are more or less contingency planning sessions and criticism of a decision they haven't made yet. Personally, I think we should wait until oVirt has made their statement publicly before going down this path. As for why the criticism is being made, I can say it has some merrit. If oVirt were to continue past RHVM's EOL, or if oVirt were to be forked by the community into a new project, accepting the RH deprecations into oVirt's design and source tree is short-sighted. At best it's them trying to avoid techincal debt and loosing (unofficial) support for RHEL. At worst, it's oVirt degrading itself in deference to RH's new shiny offering at the oVirt users' expense and detriment. Again, we're now at two functionalities that have been, or will be, removed: SPICE (which is all around better than the suggested VNC replacement) and now GlusterFS (which will cause massive downtime for those unfortunate enough to have used it as their storage backend.) Given that oVirt never really supported RHEL outright, (i.e. it's not tested on that platform), and that many of the people on this mailing list have requested support for CentOS's various replacement distros. I, and others, don't see a reason for oVirt's continuing to accept these changes. A statement on the matter would be nice. Personally, I will wait for an official annoucement from oVirt before making any decisions as well. Although, for what it's worth, I would cast my vote to retain the GlusterFS support if it's avaiable on the hosts. I was already using GlusterFS 9 packages in oVirt 4.3 and CentOS 7 so I could connect a set of raspberry pi 4 bricks to the engine. So it's not like the support cannot exist if RH doesn't provide the packages for it. (Fun home experiment. Turns out it works just fine. I can easily run 20+ VMs concurrently with this setup, and it pays for itself via the electric bill as a bonus.) -Patrick Hibbs On Sun, 2022-02-06 at 19:07 +0000, David White via Users wrote: