When OpenStack is the right layer
OpenStack is an Apache-2.0 licensed set of services that provide infrastructure as a service: compute, networking, block storage, images, object storage and identity, all exposed through APIs and a web dashboard. Teams get self-service projects with quotas, and infrastructure-as-code tools can drive it the way they drive a public cloud.
It fits organizations that need multi-tenant self-service at data center scale, telecom or research workloads, or control over where cloud resources run. It is also a large distributed system with a database cluster, a message queue and many services to patch and upgrade. If the need is a few dozen virtual machines for one team, a simpler virtualization platform may cover it with less operating effort.
Core services and their dependencies
Each service has its own API, database schema and configuration. All of them rely on shared infrastructure that needs its own HA design.
| Service | Role | Deployment note |
|---|---|---|
| Keystone | Identity, projects, roles, catalog and tokens. | Every service depends on it. Back up its fernet and credential keys. |
| Nova and Placement | Compute instances and scheduling against tracked resource inventories. | Hypervisor sizing, allocation ratios and flavors drive capacity. |
| Neutron | Tenant networks, routers, floating IPs and security groups. | Choose ML2 with OVN or Open vSwitch and the provider network layout early. |
| Cinder and Glance | Block volumes and virtual machine images. | With Ceph RBD behind both, instances can boot from copy-on-write clones. |
| Swift | Object storage with its own replication model. | Some clouds use Ceph RGW for object storage instead. |
| Octavia | Load balancers as a service. | Amphora load balancers run as service VMs on a management network; the OVN provider covers simpler layer 4 cases. |
| Shared infrastructure | MariaDB with Galera, RabbitMQ, memcached, HAProxy and keepalived. | A failure here affects every service, so size, monitor and back these up first. |
Pick deployment tooling and stay with it
The deployment tool shapes how you configure, upgrade and troubleshoot the cloud for years. Switching later is a project of its own.
Kolla-Ansible
Uses Ansible to deploy OpenStack services as Kolla-built containers. It is opinionated out of the box and allows full customization, which suits teams who want a working baseline quickly.
OpenStack-Ansible
Ansible playbooks and roles that deploy services into LXC containers or directly on hosts, with many configuration options for teams comfortable owning Ansible in depth.
OpenStack-Helm
Helm charts that run OpenStack services on Kubernetes, for organizations that already operate Kubernetes well.
Vendor distributions
Vendors package OpenStack with their own installers and support. Check how closely they track upstream and how their upgrades work.
Lay out the control, compute, network and storage planes
Run three controller nodes so Galera and RabbitMQ keep quorum through one failure, with HAProxy and keepalived presenting a virtual IP for the APIs. Monitor database replication and queue depth.
Size compute nodes from flavors, allocation ratios and failure headroom, and reserve host memory for the hypervisor. Group GPU, large-memory or NVMe hosts into aggregates for scheduling.
Decide which networks map to data center VLANs as provider networks and which are self-service overlays using Geneve or VXLAN. Plan MTU end to end, floating IP ranges and where routing happens.
Ceph is a common backend for Cinder, Glance and Nova ephemeral disks. Keep the storage network apart from tenant traffic and size it for rebuilds after a host failure.
Federate Keystone and harden the API surface
Keystone can federate with an external identity provider over SAML 2.0 or OpenID Connect while still issuing its own tokens. Mapping rules translate assertions or claims into Keystone groups and project role assignments. Horizon can use WebSSO, and command-line users can authenticate through SAML ECP or project-scoped application credentials. An LDAP backend is another option.
Agree the role model with the identity provider owner and keep cloud admin to a small group. Terminate TLS on public and internal endpoints, isolate management, storage and tenant networks, rotate service passwords and Keystone keys on a schedule, and send API audit logs to central storage.
Release series and upgrade paths
OpenStack releases every six months. Every .1 release is a SLURP release: upgrades are supported between adjacent releases and between consecutive SLURP releases, which allows a yearly upgrade cycle. Status below is as listed on releases.openstack.org in October 2026.
| Series | Released | Status | SLURP |
|---|---|---|---|
| 2027.1 Indri | Estimated March 2027 | In development | Yes |
| 2026.2 Hibiscus | September 30, 2026 | Maintained | No |
| 2026.1 Gazpacho | April 1, 2026 | Maintained | Yes |
| 2025.2 Flamingo | October 1, 2025 | Maintained | No |
| 2025.1 Epoxy | April 2, 2025 | Maintained | Yes |
| 2024.1 Caracal | April 3, 2024 | Unmaintained | Yes |
Back up, upgrade and migrate deliberately
Back up the Galera databases, service configuration, Keystone keys, certificates and the deployment tool's inventory, and store them outside the cloud. Tenant data in Cinder or Ceph needs its own backup path and a written agreement about who restores what.
Keep the cloud inside the maintained series. Rehearse each upgrade on a staging cloud built with the same tool, complete data migrations on the source release first, and plan for some API downtime, because rolling upgrades are not guaranteed between SLURP releases.
Moving workloads from VMware usually means converting disks with tools such as virt-v2v or qemu-img, installing VirtIO drivers and mapping port groups to Neutron networks. Move in waves and validate security groups and floating IPs before retiring the source.
OpenStack operating ownership
An OpenStack cloud needs a standing operations team. Agree where the cloud team's duties end and tenant duties begin.
Cloud operations
- Runs controllers, Galera, RabbitMQ and the deployment tool.
- Monitors API latency, scheduler failures, queue depth and capacity.
- Plans and executes release upgrades.
Network and storage
- Owns provider networks, overlay MTU and routing.
- Operates the Ceph cluster or arrays behind Cinder and Glance.
- Tests the failure of a network node and a storage host.
Tenants
- Own their instances, images, security groups and data.
- Request quota changes through a defined process.
- Back up application data unless a managed backup service is agreed.
Security and identity
- Maintains Keystone federation mappings and role assignments.
- Reviews admin access, policy changes and audit logs.
- Tracks OpenStack security advisories and patch status.
OpenStack deployment questions
Can we upgrade from 2025.1 Epoxy straight to 2026.2 Hibiscus?
No. Supported paths run between adjacent releases and between consecutive SLURP releases. From 2025.1 you can go to 2025.2 or directly to 2026.1, then on to 2026.2.
Should object storage come from Swift or Ceph RGW?
If Ceph already backs block storage, RGW avoids running a second storage system and provides both S3 and Swift APIs. Swift is a native OpenStack service with its own replication design and suits teams that want object storage independent of Ceph.
Do we need an internal team if DeployOpen supports the cloud?
DeployOpen can deploy, document and provide ongoing support. You still need internal owners who approve changes and handle projects, quotas and tenant requests.
Can OpenStack and Kubernetes run together?
Yes. Kubernetes clusters often run on OpenStack instances, using the OpenStack cloud provider and the Cinder CSI driver. OpenStack-Helm takes the other approach and runs OpenStack on Kubernetes.
Scope and handover
Effort depends on the number of regions and availability zones, hardware classes, network design, storage backend, identity federation, services beyond the core set and the workloads to migrate. Network design and the first upgrade rehearsal usually need more attention than the initial install.
DeployOpen plans the architecture, deploys it with the chosen tool, hardens endpoints, configures Keystone federation, sets up control plane backups, runs release upgrades and documents the cloud. Handover includes the deployment repository, network and storage diagrams, role mappings, restore evidence, an upgrade runbook with the SLURP path and a support route.
