feat(operator): apply own CRDs on startup (#84)

Author: passcod

README.md

@@ -7,17 +7,19 @@ Monitors a Kopia backup repository for "physical" backups of PostgreSQL database
 
 ## Install
 
-Generate the CRDs:
+Apply the operator manifest:
 
 ```
-cargo run --bin gen-crds > crds.yaml
+kubectl apply -f operator.yaml
 ```
 
-Apply both the CRDs and the operator:
+The operator applies its own CRDs on startup, so no separate `crds.yaml`
+step is needed. If you'd rather manage CRD lifecycle out-of-band (e.g.
+gating schema changes at install time), generate + apply them manually:
 
 ```
+cargo run --bin gen-crds > crds.yaml
 kubectl apply -f crds.yaml
-kubectl apply -f operator.yaml
 ```
 
 ## Quick start

operator.yaml

@@ -1,5 +1,7 @@
 # postgres-restore-operator install manifest
-# CRDs are not included — generate them with: cargo run --bin gen-crds
+# CRDs are installed by the operator at startup. Generate them
+# manually with `cargo run --bin gen-crds` if you want to apply them
+# out-of-band (e.g. install-time gating on schema changes).
 ---
 apiVersion: v1
 kind: Namespace
@@ -17,6 +19,10 @@ kind: ClusterRole
 metadata:
     name: postgres-restore-operator
 rules:
+    # CRD install (operator applies its own CRDs on startup).
+    - apiGroups: ["apiextensions.k8s.io"]
+      resources: ["customresourcedefinitions"]
+      verbs: ["get", "list", "create", "update", "patch"]
     # CRD access
     - apiGroups: ["pgro.bes.au"]
       resources:

src/bin/operator.rs

@@ -151,6 +151,8 @@ async fn main() -> anyhow::Result<()> {
 
 	let client = Client::try_default().await?;
 
+	postgres_restore_operator::crd_install::ensure_crds(&client).await?;
+
 	let namespace = operator_namespace();
 	let (max_concurrent_restores, kopia_image, use_port_forward) =
 		read_config(&client, &namespace).await;

src/crd_install.rs

@@ -0,0 +1,57 @@
+//! Server-side-apply the operator's own CRDs at startup.
+//!
+//! Same source of truth as the `gen-crds` binary — both call
+//! `CustomResourceExt::crd()` on the derived types. The operator applies
+//! them on boot so a fresh cluster only needs `kubectl apply -f
+//! operator.yaml` to be functional; `crds.yaml` stays around for CI /
+//! debugging / operators who prefer to manage CRD lifecycle out-of-band.
+
+use k8s_openapi::apiextensions_apiserver::pkg::apis::apiextensions::v1::CustomResourceDefinition;
+use kube::{
+	Api, Client, CustomResourceExt, ResourceExt,
+	api::{Patch, PatchParams},
+};
+use tracing::{info, warn};
+
+use crate::{
+	error::Result,
+	types::{PostgresPhysicalReplica, PostgresPhysicalRestore},
+};
+
+/// Field manager used for the SSA patch. Distinct from
+/// `postgres-restore-operator` so a manual `kubectl edit` doesn't fight
+/// the operator on CRD ownership — humans overriding CRD fields at
+/// runtime is legitimate (e.g. temporary preservation policy changes).
+const FIELD_MANAGER: &str = "postgres-restore-operator/crd";
+
+/// SSA-apply the two pgro CRDs. Idempotent — safe to call every startup
+/// and safe to run concurrently with itself across replicas.
+///
+/// Fails hard on RBAC / apiserver errors: without the CRDs the operator
+/// can't watch anything, so surfacing the error at boot beats a
+/// mysteriously-silent operator later.
+pub async fn ensure_crds(client: &Client) -> Result<()> {
+	let api: Api<CustomResourceDefinition> = Api::all(client.clone());
+	for crd in [
+		PostgresPhysicalReplica::crd(),
+		PostgresPhysicalRestore::crd(),
+	] {
+		let name = crd.name_any();
+		let value = serde_json::to_value(&crd)?;
+		match api
+			.patch(
+				&name,
+				&PatchParams::apply(FIELD_MANAGER).force(),
+				&Patch::Apply(&value),
+			)
+			.await
+		{
+			Ok(_) => info!(crd = %name, "applied CRD"),
+			Err(err) => {
+				warn!(crd = %name, error = %err, "failed to apply CRD");
+				return Err(err.into());
+			}
+		}
+	}
+	Ok(())
+}

src/lib.rs

@@ -1,6 +1,7 @@
 pub mod canopy;
 pub mod context;
 pub mod controllers;
+pub mod crd_install;
 pub mod error;
 pub mod kopia;
 pub mod metrics;