Core Components

The components of the CobaltCore stack, organized by layer. Each entry links to the reference page that documents it in depth; the way the layers fit together is described on the Architecture page.

The figure shows where the components of the first five sections sit on the management cluster.

Orchestration

The c5c3-operator (operators/c5c3/) owns the top of the stack. It reconciles a ControlPlane CR into infrastructure CRs, service CRs, and K-ORC resources, and aggregates their readiness.

CRD	API group	Description
ControlPlane	c5c3.io/v1alpha1	Top-level resource for a whole control plane: infrastructure, services, identity plane (CRD reference)
CredentialRotation	c5c3.io/v1alpha1	Rotates the admin application credential (reconciler reference)
SecretAggregate	c5c3.io/v1alpha1	Aggregates secrets from multiple sources into one consumer Secret
KeystoneService	c5c3.io/v1alpha1	Registers one service against a ControlPlane's identity plane: catalog entry and service account, from the service's own namespace (CRD reference)
KeystoneUser	c5c3.io/v1alpha1	Orders one Keystone user from a namespace a ControlPlane assigns, on the management cluster or a target cluster, and delivers its credentials as a Secret beside the order (CRD reference)
KeystoneProject	c5c3.io/v1alpha1	Orders one Keystone project in the ControlPlane's admin domain from an assigned namespace (CRD reference)
KeystoneRoleAssignment	c5c3.io/v1alpha1	Orders one role, on the namespace's role allowlist, for an ordered user on an ordered project (CRD reference)
KeystoneCatalogEntry	c5c3.io/v1alpha1	Orders one catalog entry, a service row and its endpoints, from an assigned namespace that admits catalog entries (CRD reference)
KeystoneApplicationCredential	c5c3.io/v1alpha1	Orders one application credential for an ordered user on an ordered project, rotates it on a schedule, and delivers it as a Secret beside the order (CRD reference)
MariaDBDatabase	c5c3.io/v1alpha1	Orders one database on the ControlPlane's shared MariaDB from an assigned namespace, with a user the OpenBao database engine issues and replaces every day, and delivers its credential as a Secret beside the order (CRD reference)
RabbitMQVhost	c5c3.io/v1alpha1	Orders one vhost and a user on the ControlPlane's managed message bus from an assigned namespace, rotates the user on a schedule, and delivers the credentials as a Secret beside the order (CRD reference)

Service operators

One operator per OpenStack service (operators/<service>/), all built on the scaffolding the Keystone operator establishes and all following the API-group convention <service>.openstack.c5c3.io.

Operator	CRDs	Service	Reference
keystone-operator	Keystone, KeystoneIdentityBackend	Identity	Overview
glance-operator	Glance, GlanceBackend	Image	Overview
placement-operator	Placement	Resource tracking	Overview
horizon-operator	Horizon	Dashboard	Overview
barbican-operator	Barbican, BarbicanSecretStore	Key management	Overview
ovn-operator	OVNCentral, OVNChassis	SDN control plane and chassis	Overview
neutron-operator	Neutron, NeutronMetadataAgent	Networking	Overview
cinder-operator	Cinder, CinderBackend, CinderBackupBackend	Block storage	Overview
nova-operator	Nova	Compute control plane	Overview

The ovn-operator is the exception to the one-operator-per-service rule. It manages no OpenStack service of its own; it owns the OVN and Open vSwitch layer that the Neutron ML2/OVN driver programs.

OpenStack resource management

K-ORC, the upstream OpenStack Resource Controller (API group openstack.k-orc.cloud), manages Keystone resources declaratively: domains, projects, users, application credentials, regions, catalog services, and endpoints. It is applied by a Flux Kustomization rather than a HelmRelease, and the c5c3-operator drives its CRs for the admin application credential, the service accounts, and the catalog. See K-ORC in the infrastructure manifests.

Infrastructure stack

The HelmReleases under deploy/flux-system/ install the backing services the control plane depends on. Their configuration and the CRs built on top are documented per component in Infrastructure Manifests:

• cert-manager — the base layer of the dependency graph; issues webhook and endpoint TLS certificates (section).
• mariadb-operator with a Galera MariaDB CR as the shared database backend (section).
• memcached-operator with a Memcached CR for token and content caching (section).
• rabbitmq-cluster-operator serving the RabbitmqCluster CRD behind a ControlPlane's opt-in shared message bus (section).
• garage-operator with a Garage CR providing the S3 object store that backs Glance multi-store (section).
• openbao-operator and the OpenBao proving instance, the secret store for the whole stack (section, bootstrap).
• External Secrets Operator (ESO) syncing secrets between OpenBao and the cluster in both directions (section).
• prometheus-operator CRDs so operators can ship ServiceMonitor resources without a full monitoring stack (section).

GitOps

The flux-operator manages FluxCD through a FluxInstance CR that syncs deploy/flux-system/ from Git. HelmRelease ordering is expressed as dependsOn edges with cert-manager at the base. See FluxInstance and the dependency order.

Observability and test infrastructure

Every operator exports Prometheus metrics (Keystone Operator Metrics is the reference set). The remaining pieces ship only with the kind overlay (deploy/kind/) for development and CI:

• kube-prometheus-stack and metrics-server for local metrics, and Chaos Mesh driving the chaos e2e suites — all opt-in addons documented in Infrastructure Manifests — Kind Overlay Demo Addons.
• dizzy, the load/chaos stack around victoria-metrics, used by dizzy chaos testing.
• Envoy Gateway as the demo Gateway API implementation (deploy/kind/base/); production overlays bring their own Gateway controller.
• The Tempest image (images/tempest/) executed by the Tempest test infrastructure.

Planned components

Components from the original C5C3 architecture document without an implementation in this repository are sketched under Future: the Hypervisor Cluster, the Storage Cluster, and a dedicated Management Cluster. The not-yet-onboarded OpenStack services are listed on the Architecture page.