>
> You're welcome to help with oVirt project design and discuss with the
> community the parts that you think should benefit from a re-design.

I consider these pesky little comments part of the discussion, even if I know they are not the best style.

But how much is there to discuss, if Redhat has already decided to switch to a beta base (CentOS stream) underneath oVirt?

Nobody wants bleeding edge on a hypervisor, except those who develop that hypervisor.

oVirt is supposed to deliver a higher reliability than bare metal hardware, by providing a fault tolerant design and automatic fault recovery.

But if the software stack that the HA engine builds on is more volatile than the hardware below, it simply can't do its work of increasing overall resilience: a beta OS kills the value of a HA management stack above.

Only a RHEL downstream CentOS is near solid enough to build on (unless you did fully validated oVirt node images). Bleeding edge is what you put inside the VMs, not underneath. I don't think I have heard a single oVirt *user* advocating the switch to Stream. IMHO it's political and kills oVirt's value proposition.

My next major other gripe is that to a newcomer it's not obvious from the start that the oVirt 'classic' and the HCI variant are and will most likely remain very different beasts, because they have a distinct history and essentially incompatible principles.

Classic oVirt started with shared storage, which is always turned on. Theat means idle hosts can be turned off and workloads consolidated to minimize energy consumption. It aims for the minimal number of hosts to do the job.

Gluster is all about scale out without any choke points, the more hosts the better the performance.

And when you combine both in a HCI gluster, turning off hosts requires a much better attention as to whether these hosts contribute bricks to volumes in use or not.

For a user it's quite natural to mix both, using a set of HCI nodes to provide storage and base capacity and then add pure compute nodes to provide dynamic workload expansion.

But now I'm pretty sure that's unchartered territory, because I see  terrible things happening with quota decisions when computing nodes that don't even contribute bricks to volumes are rebooted e.g. during updates.

Making the community responsible for providing a unifying vision, is asking for help a bit too late in the game.

And then classic oVirt and HCI oVirt have completely different scaling characteristics. Classic will scale from one to N hosts without any issue, but HCI won't even go from 1 to 2 or the more sensible 3 nodes. Nor does it then allow the transition from replicas to the obviously more attractive dispersion volumes as you expand from 3 to 6 or 9 nodes.

How much of a discussion will we have, when I say that I want a Gluster volume to expand/grow/shrink and transform from 1 to N bricks and transition between replicas, dispersed volumes, sharded or non sharded with oVirt seamlessly running on top?

But unfortunately that is the natural expectation any newcomer will have, just like I did, when I read all the nice things Redhat had to say about the technology.

I hope you won't dispute it's still very much a patchwork and with a very small chance of near time resolution.
_______________________________________________
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/2CIGCLM5E2CTA2VKDZZOKXGIEQDCO5VT/