Skip to content

CobaltCore ​

CobaltCore (C5C3) is a Kubernetes-native OpenStack distribution for operating Hosted Control Planes. The project website at cobaltcore.dev introduces CobaltCore as a whole. This documentation covers the c5c3/cobaltcore repository, which delivers everything needed for a self-contained OpenStack control-plane stack: from the declarative infrastructure manifests, through the service operators, to the c5c3-operator orchestration layer — built with the Operator SDK (Go), controller-runtime, and Kubebuilder. The Architecture section shows how the pieces fit together, from the implemented management/target-cluster topology to the multi-cluster target picture.

What CobaltCore does: a layer stack from bare metal provisioned and managed by IronCore, through Garden Linux on every node and Kubernetes clusters managed by Gardener, to CobaltCore operating the OpenStack control planes and the OpenStack clouds whose API serves users and tools. Why it matters: Kubernetes-native OpenStack, one resource per cloud, growth with demand, built-in day-2 operations, and open building blocks.

The layers below CobaltCore in this picture belong to the target picture. No deployment in this repository runs on IronCore or Garden Linux yet: the stack runs on a local kind cluster, or on a Gardener shoot on metal-stack in the Quick Start (metal-stack).

The Keystone operator is the reference implementation that establishes the patterns — CRD layout, sub-reconciler chain, webhooks, finalizers, instrumentation — replicated by every other service operator. Horizon, Glance, Placement, Barbican, Cinder, Nova, and Neutron with its OVN layer are onboarded on the same scaffolding. The c5c3-operator ties the services together into a single ControlPlane resource, which projects Nova through services.nova. Compute nodes join it through NovaCompute pools, which the Quick Start (metal-stack) runs on KVM; a separate compute cluster is the follow-on #1013.

Start here ​

  • Quick Start — from git clone to an authenticated Keystone API call on a local kind cluster.
  • Quick Start (Extended) — UI tours, the local-build path, the production HelmRelease, E2E, and Tempest.
  • Quick Start (ControlPlane) — bring up a full ControlPlane through the c5c3-operator.
  • Quick Start (metal-stack) — the same ControlPlane on a metal-stack cluster, where every worker is a KVM hypervisor and runs a server.
  • Quick Start (Orders) — the Keystone, MariaDB and RabbitMQ pieces of a foreign service, ordered from an assigned namespace on the management cluster and on a target cluster.

The map shows what each quick start deploys, what it ends with, and how the five relate. Four of them begin at git clone; the Quick Start (Orders) begins on the ControlPlane devstack.

A map of the five quick starts. Two of them run one standalone Keystone on a kind cluster on the workstation. The Quick Start deploys the infrastructure stack, the keystone-operator and one Keystone resource, and ends with an authenticated token. The Quick Start (Extended) is the same devstack in more depth, with the UIs, the opt-ins, local builds, the E2E suite and Tempest, and going there from the Quick Start needs make teardown-infra first, because its Step 2 creates the same cobaltcore cluster on port 443. The other three run a whole control plane from one ControlPlane resource. The Quick Start (ControlPlane) runs on a fresh kind cluster and ends with a token, an image, a secret, a network and the Horizon dashboard. The Quick Start (metal-stack) runs the same ControlPlane resource on a Gardener shoot on metal-stack, turns every worker into a KVM hypervisor, and ends with a server on every worker, a volume, a live migration, an eviction and a backup. The Quick Start (Orders) extends the ControlPlane devstack without a teardown: a second kind cluster joins it as a registered target, a service owner orders seven pieces from an assigned namespace on each cluster, and it ends with four Secrets on the target and four Jobs that use them. Going from a standalone Keystone to a ControlPlane is a mode change that needs make teardown-infra and a fresh cluster. Four of them begin at git clone; the Quick Start (Orders) begins on the ControlPlane devstack.

What's inside ​

  • Operators. Service operators following a shared sub-reconciler pattern, with Keystone as the reference implementation and the c5c3-operator as the ControlPlane orchestration layer. Horizon, Glance, Placement, Barbican, Cinder, Nova, and Neutron are onboarded on the same conventions; the OVN operator runs the SDN layer Neutron programs.
  • Shared library. Common types, conditions, config rendering, and Kubernetes helpers in internal/common/, plus the Helm chart, operator packaging, and rotation scripts. See the Backend reference.
  • Infrastructure stack. Declarative FluxCD manifests for OpenBao HA, External Secrets Operator, MariaDB, Memcached, the Envoy Gateway, and the RabbitMQ Cluster Operator behind the message bus. See Infrastructure Manifests.
  • CI/CD & container images. GitHub Actions for CI and image builds, and Nix builds for the OpenStack service images, nova-compute, libvirt and Tempest. See the CI Workflow and Nix Image Build.
  • Test suites. Unit, envtest integration, Chainsaw E2E, Tempest, and Chaos Mesh coverage across the stack — see the Testing reference.

Go deeper ​

  • Architecture — the implemented topology, the layering from Flux stack to ControlPlane orchestration, and the Core Components catalog.
  • Guides — day-2 operations, key rotation, multi-tenant deployment, identity and storage backends, target clusters, and advanced configuration.
  • Reference — CRDs, reconciler architecture, controller events, metrics, and the infrastructure, CI/CD, and testing internals.
  • Future — idea sketches for where the operators could go next.
  • Contributing — onboard a new operator or release, follow the guide conventions, and set up the development environment.

For an AI-assisted tour of the codebase, browse the repository on DeepWiki.