Why teams put OpenStack Magnum Kubernetes clusters on their private cloud
OpenStack Magnum is the OpenStack service that creates and manages container orchestration clusters, so developers can request a Kubernetes cluster from the private cloud on their own. Teams implement it when a platform or cloud team is building each cluster by hand, with different Kubernetes versions, network layouts and access rules for every group that asks. The request queue is the usual trigger, but the underlying goal is a repeatable path where the platform team decides what a cluster looks like and developers decide when they need one. Magnum makes that possible by turning those choices into a reusable definition that anyone with the right project role can apply.
Magnum does not run alone. It depends on Keystone for identity, so cluster owners authenticate with the same users, groups and projects that govern the rest of the cloud. It uses Neutron to attach cluster nodes to networks and subnets, Cinder to provide persistent volumes that workloads claim, and Heat to build the stacks that create and scale the underlying compute instances. Each of these integrations is a place where a default can quietly drift from your security model. Before the first cluster is built, decide which project owns which network, which quotas apply to a cluster and which storage options developers receive.
Installing the Magnum service is the smallest part of the engagement. The substantive work is designing cluster templates that define the Kubernetes version, node image, flavor, network driver, storage settings and cluster size that developers may choose, along with which of those fields users are allowed to change. It also covers mapping your directory groups into Keystone projects and roles, designing the network path for node and pod traffic, and defining the lifecycle model. That model answers how templates are versioned, how existing clusters move to newer versions and who is notified before a cluster is retired.
Before scoping, confirm which Magnum release matches your OpenStack release. Magnum is released alongside the rest of OpenStack, and running a Magnum release that does not correspond to your Keystone, Neutron, Cinder and Heat versions creates avoidable risk during installation and later upgrades. Ask your deployment tooling provider, or check your own packaging, which Magnum release is intended for your target OpenStack release, and confirm that release is still within its maintained window before you commit to a template design. The OpenStack release you pick also sets the upgrade path you will need to plan later.
What Magnum does for self-service Kubernetes on OpenStack
Magnum lets users request Kubernetes clusters without operating the underlying infrastructure themselves. The platform team sets the boundaries through templates, identity, networking and storage, and each card below marks where those boundaries sit. Confirm every capability against the Magnum release you plan to run, because supported options and defaults change between releases.
Cluster templates define the cluster
A cluster template fixes the image, flavor, network, storage and labels that a cluster is built from. The platform team writes and publishes templates, so decisions such as the Kubernetes image and default network stay under central control. Users request a template and supply only the choices the template leaves open, such as node count. Before go-live, confirm which template fields your release accepts and which of them users can override.
Clusters on VMs or bare metal
Magnum builds clusters through Heat on compute resources that your cloud exposes. The platform team decides whether node groups run on virtual machines, bare metal through Ironic, or both, and which flavors are offered for each. Users pick a supported flavor and node count rather than provisioning hosts themselves. Confirm the bare metal path and its image and networking prerequisites in your target release before promising it to users.
Project-scoped access through Keystone
Magnum uses Keystone to authenticate each request and scope clusters to a project, so users see and manage only the clusters their project owns. The platform team controls which roles can create clusters and how federated users from a corporate identity provider map to projects through Keystone mapping rules. Users only request cluster actions within those roles. Confirm the role names Magnum checks in your release and test that a user from one project cannot list another project's clusters.
Neutron networking for cluster traffic
Magnum places each cluster on Neutron networks, which carry node traffic, pod traffic and access to the API server. The platform team defines the networks, subnets, external gateway and any load balancer service the template uses, so cluster traffic follows the same routing and security rules as the rest of the cloud. Users select an approved network rather than designing one. Confirm which Neutron driver, security group behavior and load balancer options your Magnum release supports.
Cinder volumes for cluster storage
Magnum can attach Cinder volumes to cluster nodes and expose them to workloads, depending on the template and the Kubernetes storage integration in use. The platform team defines the volume types, the default storage class and the size limits users can request. Users ask for storage capacity within those limits. Confirm the volume types, quotas and storage driver integration your release provides, and agree on backup responsibility for persistent volumes before users depend on them.
How Magnum turns a cluster template into Heat stacks on VMs or bare metal
A cluster template is the input that defines a Kubernetes cluster in Magnum: the image, the flavor for each node role, the network and the labels that tune the deployment. When a user requests a cluster from a template, the Magnum API validates the request against that template and the user's Keystone project, then hands the infrastructure work to Heat. Heat creates one stack for the control plane nodes and another for the worker nodes, and Nova boots each instance from the image named in the template. That image carries the Kubernetes components and the container runtime, so a booted node already has what it needs to join the cluster. Before anyone requests a cluster, confirm which image your release expects, who builds it and how it receives security patches, because that image becomes the base of every node in the cluster.
Heat is usually where build problems first appear, so plan for reading its output. Each cluster maps to stacks with nested resources for networks, security groups, server groups, load balancers and instances, and the stack events show which resource failed and why. Magnum reports a cluster status that follows the Heat state, but the Heat events hold the detail your platform team needs to fix a failed build. Ask your team to confirm that the service user Magnum uses for Heat has the quotas and roles to create every resource the template requests. A missing quota for instances or floating addresses often shows up as a stack that stalls with an unclear error, so check quotas before the first test cluster rather than after a failed build.
Worker nodes can be virtual machines scheduled onto the hypervisors in your cloud, or bare metal instances provisioned through Ironic onto whole physical servers. Virtual workers share the hypervisor pool, so they suit elastic scaling and the standard Nova flavor and Cinder volume model, and Ceph-backed guest disks let them boot without local hypervisor storage. Bare metal workers give pods direct use of host CPU, memory, accelerators and network hardware with no hypervisor layer in between, which matters for GPU-heavy inference, latency-sensitive network functions and workloads that need the full host. The trade-offs are slower node turnaround, a dependency on hardware enrollment and cleaning, and a stricter match between flavors and physical inventory. Ironic's PXE and IPMI provisioning, enrollment and networking are covered in the Ironic topic, so read that before you commit a worker pool to bare metal.
Decide the worker type per node pool where your release allows it. A common split keeps the control plane on virtual machines and places bare metal workers only in pools that need hardware access. Before you sign off the design, check four things: that the template names the correct image for each worker type, that the Ironic side can provision the flavor you plan to use, that upgrades replace nodes in a way your spare capacity can absorb, and that a named team owns the image rebuild when Kubernetes patch releases arrive. Confirm each item against your Magnum release notes and a test cluster in your own environment, because support for mixed worker pools and bare metal templates varies by release and by driver.
Which template and control plane decisions shape each cluster
This table lists the decisions a team must settle before publishing the first Magnum cluster template, with the options, the conditions that favor each, and how hard each one is to reverse. Read the last column first, because control plane topology, network CIDRs and storage backend are the costliest to change once clusters run. Confirm driver, load balancer and identity support against the Magnum release you deploy.
| Decision | Options | When each fits | Cost to change later |
|---|---|---|---|
| Worker node type | VM instances on Nova, or bare metal instances through Ironic | VMs suit general workloads and fast scaling. Bare metal suits hardware-bound or latency-sensitive node pools. | Moderate. A new node type means new node groups and draining the old workers. |
| Control plane layout | Stacked etcd on control plane nodes, or an external etcd cluster | Stacked fits smaller clusters with fewer machines to run. External fits when etcd needs separate sizing, access control or backups. | High. Switching topology means rebuilding control plane members and migrating etcd data. |
| Control plane count and API endpoint | Three or more control plane nodes behind a TCP load balancer on port 6443 | Three or more members is the kubeadm high availability baseline. An odd etcd member count is required. | Moderate. The API address is written into kubeconfigs and joins, so set a stable DNS name first. |
| Network driver and CIDR planning | A CNI plugin that your Magnum template supports, with pod, service and node CIDRs | Choose a driver your distribution and template support (confirm in the Magnum release notes). CIDRs must not overlap corporate networks. | High. Pod and service CIDRs are hard to renumber after workloads are running. |
| Storage class backend | Cinder volumes backed by Ceph RBD, or another Cinder backend | Ceph-backed Cinder fits clusters that need shared, well-understood block storage. Other backends fit where they already run. | Moderate to high. Existing persistent volumes are tied to the backend, so migration needs a copy plan. |
| Load balancer provider | Octavia through OpenStack, or an external load balancer outside the cloud | Octavia fits teams that want Kubernetes service load balancers provisioned through OpenStack. External fits where an appliance already handles traffic. | Moderate. Services built on one provider must be re-pointed, and addresses may change. |
| Kubernetes user identity | OpenID Connect from a trusted identity provider, webhook token authentication, or X.509 client certificates | OIDC fits directory-backed users. Webhook authentication fits custom token checks. Certificates fit break-glass administrator access. | Moderate. Changing the method means reconfiguring API server settings and reissuing user access. |
| Secrets handling | Kubernetes Secrets with encryption at rest, or an external store through the Secrets Store CSI Driver | Secrets sit unencrypted in etcd by default, so encryption at rest is the minimum for regulated data. External stores fit where a central vault already exists. | Low for the choice. High if secrets already sit in etcd and must be re-encrypted and rotated. |
Implementation sequence for Magnum clusters and the output of each step
The sequence moves from version selection to a supported self-service service in eight ordered steps, and each step closes with an artifact that platform and security owners can review before the next step begins. Templates depend on the image, and user access depends on quotas and a tested restore path, so the order matters. Ask for each output in writing so progress stays visible.
Confirm Magnum and Kubernetes versions
Start by matching the Magnum release to the OpenStack release already in production or planned for it, then select the Kubernetes minor version the cluster will run. Check the Kubernetes release page and version skew policy so the chosen version has an upstream support window long enough for your planned operating period. Confirm the Magnum driver and Heat support for that Kubernetes version with your OpenStack release notes and the Magnum documentation. The output is a short compatibility record naming the OpenStack, Magnum and Kubernetes versions, the supported upgrade path and the owner who approved them.
Build and test the base image
The platform team builds the Kubernetes node image with the container runtime, kubelet and kube-proxy at the approved versions, plus hardening settings such as disabled unused services and the operating system baseline your security team requires. The image is registered in Glance and booted in a test project, where a node must register with a control plane and pass basic pod scheduling checks. The output is a tested image with a recorded checksum, build log and the list of packages it contains, which becomes the only image templates may reference.
Define the identity and project model in Keystone
Decide which projects own clusters, which groups receive the member or admin roles, and whether users come from a local Keystone or from a corporate directory through federation. If federation is used, write the mapping rules that translate identity provider attributes into Keystone groups, roles and projects, and test them with a sample of real accounts from each team. Keep the number of projects small enough to review and document who can create, delete and access clusters. The output is an approved project and role map, plus test results showing each group receives only the access it should.
Design networks and storage in Neutron and Cinder
Define the tenant network ranges, the external network that carries API and ingress traffic, the load balancer approach for the Kubernetes API and services, and the security group rules the cluster needs. In Cinder, define volume types for etcd, for persistent workloads and for node root disks, and confirm the backend, such as Ceph RBD, supports the performance and failure-domain targets your team sets. Confirm which CNI plugin the template will deploy and whether its traffic needs specific ports. The output is a network and storage design document reviewed by the networking and storage owners.
Write and test cluster templates
Write the Magnum cluster templates that reference the approved image, network, storage types and flavors, and store them in version control with change review. Each template should set the Kubernetes version, node counts, control plane layout and labels that your operations tools expect. Create test clusters from each template, then delete and recreate them to confirm the Heat stacks complete without manual edits. The output is an approved template set with a version tag per template, test results for create and delete, and a list of the parameters users may change.
Run a pilot cluster with an etcd backup and restore test
Build a pilot cluster from an approved template and run representative workloads on it, including persistent volumes and a service exposed through the load balancer. Take an etcd snapshot with etcdctl snapshot save, store it outside the cluster, and restore it into a separate environment with etcdutl so the team proves the restore works, not only that the backup file exists. Verify Secrets encryption at rest is configured, since Kubernetes stores Secrets unencrypted in etcd by default. The output is a restore record listing the snapshot time, the restore steps, the outcome and any gaps the owners accepted.
Set quotas and self-service rules
Set Nova, Neutron, Cinder and Magnum quotas for each project so one team cannot exhaust shared compute, floating IP or volume capacity. Define which templates each group may use, the maximum cluster size per project, and whether users can change node counts without approval. Set a baseline Pod Security Standards level for workload namespaces and document the expected RBAC pattern for cluster administrators. The output is a quota and policy table per project, with evidence that a test user is blocked from actions outside their allowed scope.
Open to users with runbooks
Before opening the service, publish runbooks for creating and deleting clusters, scaling node groups, rotating credentials, repairing a failed node, upgrading the Kubernetes minor version and running an etcd restore. Each runbook should name the owner, the expected inputs and the check that confirms success. Hand over monitoring dashboards and an escalation path to the support team, and schedule the first backup verification. The output is a published runbook set, a support handoff record and an access announcement that lists which projects and groups have been enabled.
Moving existing Kubernetes workloads onto Magnum clusters
Magnum creates new Kubernetes clusters from cluster templates. It does not adopt or convert clusters that already run elsewhere, so moving onto a Magnum cluster is a migration of applications, manifests, persistent data and secrets into a cluster built from scratch. Treat it as a project with its own inventory, data moves and cutover plan, separate from the work of provisioning the cluster itself. Start with an inventory of everything the old cluster does, not only the Deployments your team remembers. List namespaces, workloads, Services and Ingress objects, CronJobs, custom resources and their controllers, admission policies, RBAC bindings, and any cluster-scoped objects such as StorageClasses and CustomResourceDefinitions. For each item, record its owner, whether it is stateful, which external endpoints it depends on, and whether it can be redeployed from Git or must be exported. Helm releases and GitOps repositories often make this faster, but confirm that the live cluster matches what the repository describes before you rely on it. Persistent volumes need the most planning. Data on the old cluster may sit on storage classes that do not exist on the new cluster, so each claim must be mapped to a Cinder-backed or Ceph-backed class that Magnum's integration exposes in your environment. Confirm the CSI driver version, volume types, and whether snapshots and volume expansion are supported for each class. Choose a copy method per volume, such as application-level replication, backup and restore, or a volume-level copy, and test it on a non-production claim first. Plan the write freeze for each stateful service, because a copy taken while the application is writing may not be consistent. Secrets and certificates move differently. Kubernetes Secrets are stored unencrypted in etcd unless encryption at rest is configured, so review what the old cluster holds before exporting anything, and avoid copying plaintext secret manifests into Git. Where possible, re-issue credentials for the new environment and re-point clients to new endpoints. For ingress certificates, decide whether to reuse existing certificates, issue new ones through your certificate authority, or use an external secret store with the Secrets Store CSI Driver. Keystone and the cluster's authentication method also affect who can read these objects, so confirm access before cutover. Run the old and new clusters in parallel for as long as the business can tolerate. Move low-risk, stateless services first, shift traffic gradually at the load balancer or DNS layer, and keep rollback paths open until stateful services are verified. Etcd snapshots from the old cluster are useful for recovery and for reference, such as checking old object definitions, but restoring an etcd snapshot into a different cluster is not a general migration path. Confirm the specific tooling, such as Velero, GitOps sync or custom scripts, with your team and test it against a representative workload before the cutover window.
What drives the cost and effort of a Magnum implementation
This table lists the factors that raise or lower the effort of a Magnum implementation, who carries each piece of work, and whether it is paid once or recurs. Use it to read a quote: each driver should appear as a line item or stated assumption in the written scope. The main takeaway is that the state of the existing OpenStack estate and the upgrade commitment often matter as much as the number of clusters.
| Driver | Why it changes effort | Who carries it and how often | What to ask for in a quote |
|---|---|---|---|
| Templates and node types | Each cluster template combines image, flavor, network and labels; every extra node type adds build and test cases. | DeployOpen designs and tests templates; client platform team maintains new variants. One-time build, then recurring as variants grow. | Count of templates, node groups and supported Kubernetes versions per template. |
| Bare metal versus VM workers | Bare metal workers add Ironic provisioning, hardware enrollment and driver testing on top of Nova VM workers. | DeployOpen builds the bare metal path once; client hardware team supplies server inventory. One-time, with recurring driver updates. | Whether Ironic is in scope, server models, and the number of worker pools on each. |
| OpenStack services integrated | Each service adds configuration, credentials and failure tests: Keystone federation, Octavia, Barbican, Manila and Ironic. | DeployOpen integrates and tests; service owners review. One-time per integration, plus recurring checks after upgrades. | Which services are in scope and whether each integration is tested end to end. |
| State and release of existing OpenStack | An older or heavily customized deployment needs remediation before Magnum is added. The release sets which Kubernetes versions are practical. | Client operators own remediation; DeployOpen assesses and plans. One-time assessment, then recurring with each OpenStack release. | Current release, deployment tool, and a written list of local patches and known gaps. |
| Number of clusters and tenants | More projects and clusters multiply quotas, role mappings, network segments and onboarding runbooks. | Client platform team runs onboarding; DeployOpen builds the self-service workflow. One-time build, recurring per tenant. | Expected cluster and tenant counts at launch and expected growth assumptions. |
| Identity model | Keystone federation with mapping rules to groups, roles and projects, plus Kubernetes authentication, adds design and testing. | DeployOpen designs mappings and tests logins; client identity team supplies the identity provider. One-time, then recurring as groups change. | Identity provider protocols, group-to-project mapping rules, and who approves changes. |
| Network design complexity | Tenant networks, load balancer placement, ingress and provider networks change routing and firewall work. | DeployOpen designs and validates; client network team approves addressing. One-time design, recurring for new ranges. | Address plan, provider network list, and the load balancer and ingress path. |
| Backup and restore testing scope | etcd snapshots and restores, plus Cinder or Ceph volume backups, must be tested by restoring them into a separate environment. | DeployOpen plans and runs restore tests; client operations runs schedules. One-time test design, recurring scheduled tests. | Restore test scenarios, test frequency, and the evidence each test should produce. |
| Upgrade cadence | Magnum clusters follow Kubernetes minor releases; the control plane moves one minor version at a time, before workers. | Client commits to the cadence; DeployOpen plans and runs upgrades under a retainer. Recurring for the life of the platform. | Upgrade windows, targeted Kubernetes and OpenStack releases, and retainer scope. |
How Magnum connects to Keystone, Neutron, Cinder and the rest of the cloud
Magnum clusters sit on top of several OpenStack services, and each one sets conditions the cluster must meet before it can be built. The cards below cover the services that most often shape a rollout, the decision each one forces, and the check to run before the first cluster goes live.
Keystone federation and mapping rules
Keystone authorizes every request to create or manage a cluster, so it sets who can use Magnum and in which projects. Federation accepts identities from a trusted identity provider over SAML 2.0 or OpenID Connect, and mapping rules decide which corporate groups become OpenStack roles and which projects they reach. Decide which groups may create clusters and which may only use them. Test the mapping rules with sample accounts before go-live, because a rule that matches too broadly grants access to every project it covers.
Neutron networks for cluster traffic
Magnum places each cluster on Neutron networks, subnets and routers, so cluster traffic follows your tenant network design. Decide whether clusters share a provider network or receive isolated tenant networks, and confirm that pod and service address ranges do not overlap with networks already in use. Confirm which Neutron driver the cloud runs, because routing, DHCP and security group behavior differ between drivers. Write the security group rules that the control plane and workers need before building the first cluster.
Cinder and Ceph for persistent volumes
Persistent volumes for workloads in a Magnum cluster are typically provisioned as Cinder volumes. Ceph block devices can back Cinder volumes, backups and guest disks, which lets virtual machines boot from Ceph without local hypervisor storage. Decide which volume types map to which Ceph pools, and whether data must be replicated across failure domains. Ask the storage team how volume snapshots and backups run, since application data stored in these volumes depends on that schedule and its restore process.
Manila shares through the CSI route
Workloads that need one file system shared by several pods cannot use a single block volume, so they depend on Manila shares. Kubernetes consumes Manila shares through the Manila CSI plugin. Decide which share types and back-end driver serve the clusters, and which share networks reach the worker nodes. Confirm the plugin version that matches your OpenStack release and your Kubernetes version before you put shared storage into production.
Octavia load balancers and Barbican certificates
Octavia provides the load balancers that front the Kubernetes API and services exposed from the cluster, including the API endpoint of highly available clusters, where you should confirm the exact behavior in your release. Octavia terminates TLS with certificates held in Barbican, so Barbican must be running and its access policy set before listeners are created. Decide which team owns certificate issuance and renewal, and size load balancer capacity against the number of listeners the clusters will publish.
Ironic for bare metal worker nodes
Magnum can build clusters on virtual machines or on bare metal, and bare metal workers depend on Ironic for enrollment, PXE boot and IPMI power control. Decide which node groups need physical hardware, such as those for accelerators or latency-sensitive workloads, and which can stay virtual. Confirm the Ironic networking and cleaning steps before writing worker templates, because a failed enrollment can block an entire node group from scaling. Plan bare metal capacity as a separate pool from the hypervisor capacity.
Questions teams ask before they hire help with Magnum clusters
What drives the cost of a Magnum Kubernetes implementation?
The main cost drivers are the number of clusters, the state of your existing OpenStack cloud, and how much of the Magnum and Heat setup is new work. Scope inputs include the number of clusters and node groups, whether nodes run on virtual machines or bare metal, identity integration through Keystone, storage classes backed by Cinder or Ceph, Neutron network design, and the upgrade process you expect to run each year. One-time work covers design, cluster template creation, integration testing and handover documentation. Recurring work comes from upgrades, patching and support, which you can plan through a separate retainer. When you request a quote, ask for the written scope, the deliverables, the assumptions about your existing cloud, the test environments included, and which items are optional. A fixed-scope quote should also list the exclusions.
How long does it take to deploy Magnum clusters?
Duration depends on scope and on the cloud you already run, so ask for a schedule only after the scope is written. A new OpenStack deployment needs a stable cloud before cluster templates are useful, which adds time before any cluster is built. The factors that move the timeline most are whether your OpenStack release is current or needs an upgrade first, whether Keystone federation with your corporate directory is already in place, which storage backend you use, how many cluster templates you need, the validation your organization requires, and the change windows your teams can approve. Ask for a schedule tied to written milestones, with the dependencies on your side named explicitly so that delays can be traced to a cause.
What does our team need to provide before work starts?
Your team provides access and decisions. Cloud administrators need OpenStack accounts with the roles required to manage projects, networks, images, volumes and Heat stacks. Network and DNS owners confirm address plans and name resolution. Identity administrators review the Keystone mapping rules that connect your directory to OpenStack groups, roles and projects. Storage owners confirm Cinder and Ceph capacity and backup targets. Security reviewers set the expectations for Pod Security, secrets handling and access to the Kubernetes API. You should also name one owner who approves designs and changes. Where possible, provide a test environment that resembles production, your change process, sample workloads, and your standards for images and cluster templates.
Can our internal team build Magnum clusters without outside help?
Yes, an internal team can build Magnum clusters alone if it has OpenStack operators who understand Keystone, Neutron, Cinder and Heat, and Kubernetes engineers who can handle etcd backups, control plane high availability and upgrades. The gaps usually appear in the less visible work: upgrade rehearsals, cluster template governance, recovery testing and keeping pace with the release cycles of both OpenStack and Kubernetes. To test your readiness, check whether your team can name an owner for each upgrade task, restore an etcd snapshot in a lab, and explain how a template change reaches existing clusters. If the answers are unclear, a partner can cover the gaps under a fixed scope while your staff learn the workflow. The decision should rest on current skills and on your capacity to maintain the platform after go-live.
How do Kubernetes version releases affect a Magnum upgrade plan?
Kubernetes version releases shape the plan because the project maintains only its three most recent minor releases. It ships approximately three times a year on a cycle of about 14 weeks, and as of September 2026 the maintained minor releases were 1.37, 1.36 and 1.35. Each Magnum cluster template pins an image and a Kubernetes version, so every upgrade needs a new image, a test cluster and a controlled rollout. The version skew policy requires kube-apiserver to move one minor version at a time and allows kubelets to run up to three minor versions behind it. Plan Kubernetes upgrades as a recurring task with a tested image, a test cluster and a rollout schedule. Before you commit, confirm which Kubernetes versions your Magnum release and image build support.
Can DeployOpen run our Magnum clusters after handover through a retainer?
Yes. DeployOpen offers retainers for ongoing support, upgrades and continuous testing of the systems it implements in your environment. For Magnum clusters, a retainer can cover review of cluster health, Kubernetes and template upgrades, OpenStack upgrades planned under the SLURP cadence, etcd backup checks and security testing. Scope the retainer in writing: which clusters and environments are covered, the response expectations you agree to, the upgrade windows, and what is excluded, such as new cluster templates or new integrations. The clusters remain in your own cloud, and the access model should be confirmed during scoping. Ask whether the retainer includes OpenStack upgrades, Kubernetes minor version upgrades, or both, and how changes are tested before they reach production.
Which OpenStack release should our Magnum plan target?
Target a current release line and confirm the Magnum version that ships with it. OpenStack 2026.1 Gazpacho is a SLURP release that was released on 2026-04-01, and 2026.2 Hibiscus followed on 2026-09-30. The 2025.1 Epoxy and 2025.2 Flamingo releases remain in the maintained phase. SLURP releases support upgrades between them, which gives your OpenStack platform a planned upgrade path under your Magnum clusters. Stable branches are maintained for approximately 18 months, so the release you choose sets how long fixes arrive. Before design begins, confirm with your team that the Magnum driver, Heat and the Kubernetes image builds you need are supported on the chosen release.
How DeployOpen scopes, delivers and supports a Magnum implementation
DeployOpen treats a Magnum deployment as two systems to plan together: the OpenStack services that provide projects, identity, networking, storage and VM or bare metal capacity, and the Kubernetes clusters that run on top of them. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers.
How we scope
- The written scope names the Magnum version, OpenStack release and the Heat, Keystone, Neutron and Cinder integrations in use.
- Cluster templates list Kubernetes versions, node flavors, network drivers and whether nodes run on VMs or bare metal.
- The upgrade path for OpenStack and each Kubernetes minor version is written down before build starts, with named owners.
How we build
- Keystone, Neutron and Cinder are checked before any Magnum cluster is created from a template.
- etcd sized with an odd member count, snapshot backups via etcdctl and restores rehearsed with etcdutl.
- Secrets handling covers encryption at rest for etcd, least-privilege RBAC and the choice of an external secret store.
How we hand over
- Handover includes a runbook for creating, scaling, upgrading and deleting clusters through the Magnum API and CLI.
- Documentation covers template ownership, Keystone project and quota mapping, and which team approves each change.
- Test evidence from build, upgrade rehearsal and backup restore is delivered with the cluster configuration.
How we support
- Retainers can cover Kubernetes patch releases, Magnum and OpenStack maintenance and periodic upgrade rehearsals.
- Upgrades follow the Kubernetes version skew policy, moving the API server one minor version at a time.
- Operating checks cover Kubernetes release end-of-life dates, OpenStack SLURP timing and clusters that fall behind.
