> On Tue, Feb 15, 2022 at 8:50 PM Thomas Hoberg <thomas(a)hoberg.net&gt; 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,
_______________________________________________
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/LLCYMVWNC6F5E4RYIOSKNGI7Z3D4GLLA/

Reply via email to