Skip to content

refactor: Extract apply and update_status steps - #772

Open
maltesander wants to merge 4 commits into
mainfrom
refactor/apply-and-status-steps
Open

refactor: Extract apply and update_status steps#772
maltesander wants to merge 4 commits into
mainfrom
refactor/apply-and-status-steps

Conversation

@maltesander

Copy link
Copy Markdown
Member

Description

  • Extracts an apply step (controller/apply.rs). The Applier owns the ClusterResources handle, applies every resource kind in a defined order and deletes orphaned resources. The ServiceAccount and RoleBinding go first (the Pods reference them at creation time), the StatefulSets and Deployments last (so every ConfigMap and Secret they mount already exists, see StatefulSet restarter always restarts replica 0 immediately after initial rollout commons-operator#111).
  • Extracts an update_status step (controller/update_status.rs).
  • Adds a typestate marker to KubernetesResources. The build step returns Prepared, the applier returns Applied, and update_status only accepts Applied, so the compiler proves that the cluster status is derived from the resources the API server returned rather than from the ones that were merely built. The applier destructures the bundle without a rest pattern, so a resource kind added later fails to compile instead of silently never being applied.
  • Moves the SECRET_KEY Secret creation into the apply step, where the other client side work lives.
  • Removes the SDP 26.3 to 26.7 SECRET_KEY migration, which is no longer needed now that 26.7 is released. Closes Remove 26.3 - >26.7 SECRET_KEY migration task #755.

Author

  • Changes are OpenShift compatible
  • CRD changes approved
  • CRD documentation for all fields, following the style guide.
  • Helm chart can be installed and deployed operator works
  • Integration tests passed (for non trivial changes)
  • Changes need to be "offline" compatible
  • Links to generated (nightly) docs added
  • Release note snippet added

Reviewer

  • Code contains useful comments
  • Code contains useful logging statements
  • (Integration-)Test cases added
  • Documentation added or updated. Follows the style guide.
  • Changelog updated
  • Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

  • Feature Tracker has been updated
  • Proper release label has been added
  • Links to generated (nightly) docs added
  • Release note snippet added
  • Add type/deprecation label & add to the deprecation schedule
  • Add type/experimental label & add to the experimental features tracker

Makes KubernetesResources generic over a marker that records how far the
resources have progressed through the reconciliation. The build step now
returns KubernetesResources<Prepared>, meaning built but not yet applied.
Moves resource application out of the reconcile function into a dedicated
controller/apply.rs. The Applier owns the ClusterResources handle, applies
every resource kind in a defined order and deletes orphaned resources,
returning KubernetesResources<Applied> so that later steps can rely on the
resources having reached the API server.

The ServiceAccount and RoleBinding are applied first because the Pods
reference them at creation time, and the StatefulSets and Deployments last
so that every ConfigMap and Secret they mount already exists (see
commons-operator#111). The resource bundle is destructured without a rest
pattern, so a resource kind added later fails to compile here rather than
silently never being applied.

The SECRET_KEY Secret handling (random creation plus the temporary 26.3
migration) moves along with it, since it is a client-side concern that has
to happen before the resources mounting it are applied. The owner
reference of the migrated Secret is now derived from the ValidatedCluster,
which yields the same reference but is infallible.
Moves the cluster status computation out of the reconcile function into a
dedicated controller/update_status.rs. The function takes the resources as
KubernetesResources<Applied>, so the compiler enforces that the conditions
are derived from what the API server returned rather than from what was
merely built.

The Node role contributes StatefulSet conditions and the Worker and Beat
Celery roles contribute Deployment conditions, as before.

With this the reconcile function is pure orchestration: dereference,
validate, build, ensure secrets, apply, update status. Its doc comment now
lists those steps and records which of them need a Kubernetes client.
@maltesander maltesander self-assigned this Aug 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Remove 26.3 - >26.7 SECRET_KEY migration task

1 participant