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.

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)

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

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, 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.