Skip to content

roadmap.md

Latest commit

 

History

History
99 lines (76 loc) · 4.76 KB

roadmap.md

File metadata and controls

99 lines (76 loc) · 4.76 KB
Raw

Roadmap

Goals

Build an operator that can deploy and reconcile a working OpenStack control plane on Kubernetes.

  • Declarative deployment: users describe the desired control plane in CRs; the operator converges the cluster to match.
  • Repeatable wiring: consistent handling of endpoints, credentials, service discovery, and rendered config.
  • Day-2 operability: Conditions/events/metrics explain what is blocked and what changed. (In progress; status reporting today is limited; see Architecture.)
  • Service-first structure: OpenStack is modeled as a set of services (e.g., Keystone, Nova, Neutron) that are composed into a deployment.

Non-goals

  • Full OpenStack lifecycle management for all upgrades by changing an image tag.
  • Automatic orchestration of every cross-service upgrade sequence.
  • Managing every prerequisite dependency (database, message queue, storage) inside the operator.

Motivation

  • Kolla and OpenStack-Helm do not expose a Kubernetes-native API schema for "what is configurable", which makes configuration discovery and navigation harder.
  • Kolla primarily orchestrates containers imperatively (historically via Ansible), which does not provide a reconciled, controller-driven steady state.
  • OpenStack-Helm has a high entry cost and often assumes significant OpenStack/Kubernetes expertise to operate successfully.

Planned work

The operator does day-1 provisioning well, but a lot of the design intent is not yet implemented. This page collects the planned work so the rest of the documentation can describe only what exists today. Nothing here is a commitment or a schedule; it is a record of known gaps and direction.

Status and observability

  • Cluster status. OpenStackCluster never writes status today. Planned: observedGeneration, a Ready rollup, and Reconciling / Blocked / Degraded / InvalidSpec conditions that point at the specific failing child resource.
  • Per-service conditions. Only Keystone reports Ready. The other six services have empty status structs; they should each surface readiness.
  • Events. No Kubernetes Events are emitted. Planned for transitions to blocked/degraded states and for bootstrap completion.
  • Metrics. Only the default controller-runtime metrics are exposed.

External-service integration

  • Sub-conditions. The ExternalServiceReconciler performs real reachability and auth checks for all five dependency types and writes a single Ready condition. The design calls for finer-grained SecretResolved, EndpointReachable, Authenticated, and TLSReady sub-conditions.
  • Gate rollout on readiness. Service rollout is not yet gated on external-service readiness; services proceed independently and rely on retries.

Configuration and drift

  • Drift reconciliation. Bootstrap steps run once (tracked by annotations) and are not re-run when inputs change. Ongoing reconciliation of rendered config against running workloads is not implemented.
  • Retry on failed steps. A failed bootstrap Job blocks its step until an operator deletes it. Automatic, bounded retry with clear status is desirable.

Security

  • TLS everywhere. Public endpoints are plain HTTP; rendered service configs largely ignore the tls blocks on external services. Only the external-service checks and the Glance S3 client honour TLS today.
  • Secret hygiene. Unresolved credentials fall back to well-known development passwords. Production deployments need enforced, unique secrets and no insecure defaults.

Topology

  • Multi-AZ. Availability-zone handling currently keys off the first AZ only (naming and selector). True multi-AZ scheduling is not yet supported.
  • Validation webhooks. The only schema validation is CEL on OpenStackExternalService. Admission webhooks for shape/reference validation are a design goal.

Lifecycle

  • Upgrades. There is no upgrade support at all: no spec.version, no upgrade state machine, no version policy. The intended direction treats an upgrade as a controlled transition (status.currentVersion → spec.version) executed as an idempotent, status-tracked sequence of phases (preflight, prepare, migrate, roll control plane, post-migrate, roll data plane, verify), supporting only a small, explicit version graph (adjacent upgrades). None of this is built.

Packaging

  • Published images. Glance, Nova, and Neutron require locally built images (localhost/{glance,nova,neutron}:latest); there is no image registry pipeline.
  • Install tooling. A Helm chart exists at charts/openstack-operator/ but is not published to a chart repository; there is no Kustomize overlay set or OLM bundle.
  • CI. There is no continuous integration configured.