OpenStack

Thu, 14 May 2026 00:00:00 +0000

OpenStack is an open-source IaaS platform — it turns a pool of bare-metal servers into a self-service cloud: virtual machines, block storage, networking, and object storage, all driven by API.

https://www.openstack.org/

Scale and fit

There is a rough spectrum of virtualization tools, and picking the wrong tier is a common mistake:

Proxmox / VMware / Hyper-V — the right choice when you want to run virtual machines. SMB, homelab, or a small ops team managing infrastructure directly. Reasonable setup cost, manageable operational overhead, one or a few admins in control. Think of it as a VMware replacement.

OpenStack — the right choice when you are building a cloud, not just running VMs. Multi-tenant infrastructure where teams self-service their own compute, networking, and storage via API. The operational complexity is real and significant; it pays off when the cloud-like abstraction is the actual product, or when the scale justifies the overhead.

The rule of thumb: if the question is “how do I replace VMware?”, the answer is Proxmox. If the question is “how do I build a private cloud platform?”, the answer might be OpenStack.

Core Components

Service	Code Name	What it does
Compute	Nova	Schedules and manages VM lifecycle
Networking	Neutron	Virtual networks, routers, floating IPs, security groups
Block Storage	Cinder	Persistent volumes attached to VMs
Image Service	Glance	Stores and serves OS images
Identity	Keystone	Auth, service catalog, RBAC
Dashboard	Horizon	Web UI (optional)
Object Storage	Swift	S3-like object storage (optional)
Bare Metal	Ironic	Provisions physical machines instead of VMs

You do not need all of them. A minimal useful deployment is Nova + Neutron + Cinder + Glance + Keystone.

OpenStack on Kubernetes

OpenStack services are just applications — and they can run as Kubernetes workloads. Two projects make this practical:

OpenStack-Helm — official Helm charts for deploying OpenStack services on an existing Kubernetes cluster. Each service (Nova, Neutron, Cinder, etc.) becomes a Helm release. Upgrades follow standard rolling deployment patterns.

Atmosphere (by VEXXHOST) — a higher-level operator built on top of OpenStack-Helm. Adds Ansible automation, health checks, and a more opinionated deployment model. Targets production use.

The practical implication: you can run a Talos cluster and deploy OpenStack on top of it — OpenStack as a tenant of Kubernetes rather than a separate platform. This inverts the usual relationship (where Kubernetes runs on top of OpenStack) and is an interesting architectural option for homelab and small private cloud deployments.

Fairbanks (Dutch hosting company specialising in sovereign private clouds) does exactly this in production. Their talk OpenStack on Talos Linux is the clearest real-world example of the pattern.

Deployment Options

Kolla-Ansible
https://docs.openstack.org/kolla-ansible/latest/
Containerised OpenStack deployed via Ansible. Production-grade, well-maintained. The practical choice for homelab and small-scale production deployments. Each service runs in its own container.

DevStack
https://docs.openstack.org/devstack/latest/
All-in-one development install. Not for production or anything you want to survive a reboot. Good for learning the API surface.

Canonical OpenStack (Juju / Sunbeam)
https://ubuntu.com/openstack
Ubuntu-opinionated deployment. Sunbeam is a newer minimal footprint option. Good if you’re already in the Ubuntu/Juju ecosystem.

Concepts Worth Understanding

Flavors — VM sizing templates (vCPU, RAM, disk). You define these; instances pick from them.

Security Groups — stateful firewall rules applied per-port. Default-deny inbound.

Floating IPs — externally routable IPs that can be associated/disassociated from instances dynamically.

Availability Zones — logical groupings of compute nodes. Useful for fault isolation even at small scale.

Hypervisors — Nova supports KVM (default), QEMU, VMware, and others. KVM on Linux is the standard.

Relevance to the Lab

The LLM training experiment plans to use OpenStack as the IaaS layer over the blade nodes in ASGARD — Nova for compute scheduling, Neutron for cluster networking, Cinder for shared model/dataset storage backed by Ceph.

Kubernetes Across the Stack

Mon, 16 Mar 2026 00:00:00 +0000

A documented comparison of running Kubernetes across every major hosting model — cloud managed, self-managed on cloud, private cloud, and bare metal at home. The goal is a honest, practical reference for each environment: what it costs you in time and money, where the rough edges are, and how the networking story differs between them.

The thread running through all of it is Talos Linux — an immutable, API-driven OS built specifically for Kubernetes. No SSH, no shell, no config drift. The same OS everywhere means the operational model stays consistent regardless of what is running underneath.

Environment	Approach
OpenStack — Cleura	Talos & Terraform	draft exists
OpenStack — Cleura	Talos, with Omni	maybe ?
OpenStack — ElastX	Talos & Terraform	draft exists
OpenStack — ElastX	Talos, with Omni	maybe ?
Homelab — bare metal	Talos + Pixieboot + Omni	draft exists
Homelab — bare metal	Talos + Pixieboot without Omni	maybe ?
Homelab — OpenStack	OpenStack on bare metal, Talos running on top	(stretch)
Homelab — OpenStack	Talos on bare metal, OpenStack inside cluster	(stretch)
AWS	Talos on EC2	(stretch)
Azure	Talos on VMs	(stretch)
GCP	Talos on Compute Engine	(stretch)

Stretch goals

AWS, Azure, GCP — same Talos approach, different underlying infrastructure. Interesting eventually, but not the priority.

Omni

Omni is Sidero’s managed control plane for Talos clusters — worth documenting both with and without it. Without Omni gives you the full picture of what Talos management looks like manually; with Omni shows what the managed layer buys you.

Homelab provisioning

Nodes provisioned via Pixieboot — no USB sticks, no manual installations. A node powers on, boots from the network, and registers. The goal is a fully reproducible cluster from scratch with minimal human steps.

Scope

Cluster provisioning and bootstrap for each environment
Networking — CNI choices, ingress, cross-cluster connectivity
Storage — what you get managed vs what you have to bring yourself
Operational differences — upgrades, node management, observability
Cost and trade-off summary across environments

Making it usable

Getting a cluster running is the easy part. Making it usable is where environments diverge. Each environment needs an answer for ingress, DNS, and storage — and the answer varies significantly depending on what the underlying platform provides.

On managed cloud you can lean on load balancers and block storage from the provider. On OpenStack you have those options if the provider exposes them. On bare metal at home you are on your own — MetalLB or similar for load balancer IPs, a local DNS solution, and either local storage or something like Rook/Ceph. Same Kubernetes, very different operational story underneath.

Notes exist in various states — pulling them together, testing, and documenting properly is the work.

Cloud on Backend Engineering Strategy Tools