On Tue, Feb 15, 2022 at 8:50 PM Thomas Hoberg
<thomas(a)hoberg.net> wrote:
For quite some time, ovirt-system-tests did test also HCI, routinely.
Admittedly, this flow never had the breadth of the "plain" (separate
storage) flows.
I've known virtualization from the days of the VM/370. And I immediately ran and
bought the very first VMware [1.0] product, when they did this nice trick of using the SMM
and binary translation to implement a hypervisor on an architecture that excluded VM
(except the virtual 8086) [IMHO] on purpose.
I did follow the hypervisor wars, but settled on OpenVZ because it delivered compliance,
which wasn't firmly established for hypervisors at the time and much better
consolidation. Redhat then took a very arrogant stance against containers at the time,
perhaps because Parallels (OpenVZ) and LXC (Canonical) were competitors or simply because
it had just "won" with Qumranet/KVM against Citrix/Xen: I could not convince my
Redhat contacts that it wasn't an either/or choice, but that both approaches were
complimentary. Well SuSE didn't listen either, nor did Oracle for that matter.
It took Docker to break that lose and it took Google brushing up their
let-me-containerise-that into Kubernetes to burn Redhat into action and ditch their first
OpenShift (sorry, if I don't remember every detail).
Nobody had a perfect grasp of where things were going nor the perfect product offer and
there was quite a lot of politics involved as well: not every decision was based on
technical merit.
I came back to VM orchestration because I went from compliance driven production
architecture to supporting our research labs, which needed GPU support for ML and the
ability to run set of PoC machines, both stable and without (compliance oriented)
production support teams. They also needed transportable setups, that could be shipped
around the world and operated without local support.
oVirt offered a turn-key HCI solution with a reasonable minimum of three nodes, which
could be scaled up or out within one or two orders of computing power magnitude. Any
single fault could reasonably survive a day or week-end, until a spare box could be
obtained locally and put in place. Even a double fault wouldn't necessarily result in
a complete loss or shutdown, just a define minimal operations mode, ready for
self-recovery, once the hardware was replaced: so perfect, in theory, I was positively in
love... That love is at the root of my current disillusionment, for sure, but it was you
who showed the "entire enterprise" t*ts!
At the same time it offered the ability grow into something much bigger with dedicated
storage (and skills), because I understood well enough, that you won't run a cloud on
HCI.
oVirt was like a hybrid car and could run on batteries or fuel.
Most importantly it offered running things in a "labs mode" using oVirt and
CentOS and in a "production mode" using RHEL and RHV, so if one of your
prototypes got customers, we could just switch it over to our production teams who know
how to handle auditors looking into every nook and cranny.
So the hybrid car could have air-bags and ESP all around for the Autobahn, or sand buggies
in the dunes.
These four options are gone now, rather suddenly and with little warning; there is only
one variant left, which is in full metamorphosis.
It's no longer hybrid, HCI is gone. And there is no longer a choice between a
compliant safe version and the devil-may-care agile variant, that won't always run
after every change and close any vulnerability before the cyberwar reaches you.
OpenShift with kubevirt may well point much better in the direction of where the industry
is going, but it's far from the turnkey fault resilient set of boxes, which you could
just put everywhere and have fixed by people who'd just unpack a replacement box and
rewire three cables, letting the HCI cluster heal itself.
It's also a complete inversion where etcd runs VMs as if they were containers while
oVirt ran VMs, ...that might have containers in them.
And that may be a good thing to have, for those who want that.
And that even includes me and my company, who is running OpenShift on RHEL in the big data
centers.
It's just that for the labs and in the field, this doesn't fit, an HCI setup is
what we need below, while we'll happily run OpenShift and (nested) kubevirt on top, to
ensure our software is keeping with the times as it evolves.
Now that it's finally in the open that 3/4 oVirt/RHV/HCI options are gone, I'd
like to help those who like me need one or three of them for their business.
You should help and support that, because you shouldn't want happy oVirt'lers to
be stranded and potentially angry.
There isn't even an issue of competition any more, because the Xen guys aren't
selling Kubernetes, just running that, with CoreOS, RHEL or whatnot inside VMs.
oVirt and Gluster teams did work in cooperation.
I am not sure that Nir's statement is actually that significant. It
clarifies more the organizational structure within Red Hat than the
intended quality of all relevant projects (and products). You can see
Red Hat's lifecycle pages for the relevant products to see Red Hat's
plans for them.
I think it was already clear, but if not, clarifying: From Red Hat's
POV, the replacement of Gluster is Ceph, and the replacement of oVirt
is kubevirt/OpenShift Virtualization/OKD Virtualization. This
definitely does not mean that oVirt is intended to die - on the
contrary - quite a lot of what we did in recent months was in order to
make it easier to allow oVirt to survive after Red Hat's involvement
diminishes.
Please put that on the home page, update the Wikis, tell the story.
It's not a bad story, it's just a complete rewrite of the original book as a
vSphere inspired Open Source blend.
And I'd love to have an open discussion about why oVirt couldn't also be *the* HCI
solution that everybody has at home running on three Raspberry PI for a bullet proof home
edge.
Better yet: How can it become that going forward?
>
>
> Agreed.
>
> Best regards,