Can We Use OpenStack?
"Where's OpenStack" has been the #1 question I get after releasing my fourth cloud assessment.
Years ago I failed a job interview on one question. The interviewer asked how I’d deploy a container in OpenStack. I couldn’t begin to answer.
I thought I’d blanked. I hadn’t. The question has no answer. OpenStack doesn’t deploy containers — you stand up Kubernetes on OpenStack and deploy the container there. The community tried four times to close that gap (nova-docker, Magnum, Zun, Kuryr) and abandoned every attempt. I’d been asked to describe a door that was never built.
I think about that interview every time someone asks me “can we use OpenStack?” — because almost nobody asking that question is actually asking it. They’re asking one of three different questions wearing the same word, and the whole job is figuring out which.
The test that sorts them is one sentence: do you need self-service VMs in a multi-tenant operating model?
1. The Refugee. If the honest answer is no, but we have a VMware bill and need out — you don’t want OpenStack. You want the platform Kubernetes already became. KubeVirt pulls your VMs into the container plane; VMs and containers share one scheduler, one identity model, one operational surface. OpenStack is the harder road to a place Red Hat OpenShift will take you on a paved one. Every “why not OpenStack” of this kind is really “why not Kubernetes,” and the answer is: no reason.
2. The Sovereign. If the answer is no, but we need open-source infrastructure nobody can take from us — now OpenStack is real. Canonical’s distribution gives you the strongest exit rights I’ve measured: nothing captive, everything portable, vendor genuinely swappable. The price is a standing engineering organization. Firmware lifecycle? You own the curation. Four identity planes to stitch — Keystone, MAAS, Juju, the app estate? Yours to bridge. You buy maximum authority and pay for it in headcount, forever. Fair trade, made with eyes open.
3. The Operator. And if the answer is yes — carriers, sovereign clouds, GPU operators, research federations renting to tenants who are each other’s competitors — then OpenStack isn’t a compromise. It’s the category-defining tool, and it’s no accident this is exactly where OpenStack actually lives. Multi-tenant VMs with a real isolation boundary are the one thing Kubernetes namespaces still can’t give you. This is why OpenStack settled into telco and never left.
Three buyers. Three different right answers. One word hiding which one is asking.
I’ve started publishing these as a measurement instrument — the Fourth Cloud assessment at cloud.layer2c.com — scoring control planes function by function on capability and on who actually holds authority. The Canonical OpenStack assessment is the newest. But the scores aren’t the point. The point is the question underneath the question.
So before you ask whether you can use OpenStack, answer the one-sentence test. It tells you which question you’re really asking — and two times out of three, the answer isn’t OpenStack at all.
Good framework, and the one-sentence test is sharp — but it's too generous to KubeVirt on the Refugee leg, and networking is where that shows.
KubeVirt isn't a virtualization platform; it's a VM runtime that wraps a VM inside a pod, so VM networking is only ever as capable as your CNI. Fine for flat, single-network workloads. But the moment a VMware refugee needs what they actually had — isolated tenant networks, per-port L2/L3 security, overlay and live migration together, SR-IOV that survives a migration — they're hand-stitching Multus, NADs and CNI-specific features, several still alpha or feature-gated.
Two concrete gaps: Kubernetes NetworkPolicy only governs the primary pod interface, so microsegmentation on the secondary networks VMs actually use needs MultiNetworkPolicy, which in practice means OVN-Kubernetes. And live migration — the thing people are really leaving VMware for — is conditional: the default masquerade binding can't migrate at all, bridge-mode is CNI-dependent, and overlay-plus-migration still isn't shipped on some major CNIs. In Nova+Neutron it preserves the network transparently regardless of topology, and has for over a decade.
Neutron gives you one tenant-facing API — security groups on every port, self-service routers, floating IPs, QoS, trunk ports, BGP — battle-tested in exactly the telco environments you cite. KubeVirt is closing on a subset of that, fast, but "the paved road to where OpenStack goes" oversells how paved it is.
One factual note: Magnum isn't abandoned. It's actively maintained (2025.1, now Cluster-API-driven) and does exactly what you call the right answer — stand up Kubernetes on OpenStack via a native, multi-tenant API. Citing it as a failed attempt undercuts your own recommendation.