6:50 a.m.
Il giorno mer 21 apr 2021 alle ore 11:02 Thomas Hoberg <thomas(a)hoberg.net>
ha scritto:
>
> 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.
I can understand the position here, but the fact that oVirt is developed
and stabilized against CentOS Stream which is upstream to RHEL doesn't
prevent you to run oVirt on RHEL or any other RHEL rebuild on production.
If you face any issue running oVirt on top of a downstream to CentOS Stream
please report a bug for it and we'll be happy to handle.
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.
And I understand the point of view on this and I've nothing against this.
CentOS Linux 8 is going to reach EOL in a few months and oVirt project
can't keep using it for development.
CentOS Stream is upstream to whatever CentOS Stream derivative (including
RHEL) oVirt users are going to use in production so we need to ensure oVirt
will run on what's coming next in order to avoid oVirt users to get broken
systems once an update will come to production. So from oVirt development
perspective CentOS Stream right now is the only choice.
That said, really, on production you are not required to use CentOS Stream
if you don't want to.
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.
And this can be made more clear either on the download page or in the
installation guide documentation for new comers.
Let's do it. I can open a PR on https://github.com/oVirt/ovirt-site or you
can do it and we can work together on ensuring this will be clear for new
comers.
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?
I'll let Gluster team discuss this, I lack the needed knowledge to give
meaningful replies.
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(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/2CIGCLM5E2C...
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
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.*