feat(infra): cut prod backups over to the Barman Cloud Plugin (primaryUpdateMethod: restart)

What this does

Cuts the production main CNPG cluster (tuist-tuist-pg, 3 instances) over from in-tree barmanObjectStore to the Barman Cloud Plugin, using primaryUpdateMethod: restart for the roll instead of the default switchover.

• Templates primaryUpdateMethod in the chart (default switchover, unchanged for every other cluster).
• Sets postgresql.cnpg.primaryUpdateMethod: restart in values-managed-production.yaml. Prod already has plugin.enabled: true (from #11564), so this is the piece that makes the cutover actually work.

Why restart (this is the whole point)

The default switchover deadlocked the canary cutover on 2026-07-04: flipping to the plugin changes the primary’s archive command to the plugin immediately, but the old primary pod has no sidecar yet, so it can’t archive — and CNPG’s graceful switchover hangs indefinitely waiting for it to archive its final WAL. The operator wedged with no primary for ~25 min (canary DB write-down); recovery needed break-glass.

restart recreates the primary in place (no handoff to a replica, so nothing to gate on archiving). Validated on staging (2026-07-04): the replica rolled to get its sidecar, the primary was recreated in place, the cluster re-elected a primary, and Working WAL archiving went green — no deadlock.

What merging does — MERGE IN A LOW-TRAFFIC WINDOW

Merging triggers the prod cascade (canary → acceptance → production). Canary is already on the plugin, so its deploy is a no-op. Production then cuts over, and the restart roll causes a bounded ~3 min window with no writable primary while the primary pod recreates. Treat it like a planned maintenance blip — merge at the start of a quiet window. Draft until you pick the window.

Recovery net (proven)

If the roll sticks anyway (no primary, operator looping “switchover in progress”), with the break-glass kubeconfig:

kubectl -n tuist delete pod <old-primary> --grace-period=0 --force
kubectl -n platform rollout restart deploy/platform-cloudnative-pg

CNPG then promotes the caught-up sync standby — lossless (RPO 0, quorum sync). This is exactly how canary was recovered.

Follow-ups

• After prod is confirmed on the plugin (archiving green + a restore drill), revert primaryUpdateMethod back to the default switchover so future operator bumps keep their seconds-long blip instead of a ~3 min restart.
• tuist-ops (single-instance, prod-only, separate chart) is out of scope here — it has no replica to switch to, so it just restarts its one pod and can’t hit this deadlock; it’ll cut over safely on its own next deploy.

Validation

helm template renders prod with primaryUpdateMethod: restart + the plugin path (plugins/ObjectStore/method: plugin, no barmanObjectStore); every other env still renders switchover. Staging proved the method end-to-end.

🤖 Generated with Claude Code

No GitHub comments yet.