feat(infra): install Barman Cloud Plugin everywhere + flag-gated backup migration (default off)

What this does

The CNPG operator catch-up is done (prod runs 1.29.1). This PR is the groundwork for moving backups off the deprecated in-tree barmanObjectStore to the Barman Cloud Plugin (CNPG-I), plus the README “catch-up complete” cleanup. It does not change any backups on merge — it installs the plugin and adds a flag-gated cutover path that’s default off.

Three parts:

1. Install the plugin on every cluster. Adds the official plugin-barman-cloud chart (0.7.0, same cloudnative-pg Helm repo as the operator) as a platform chart dependency, toggled by plugin-barman-cloud.enabled (on by default for managed clusters). As a subchart of the platform release it installs into the platform namespace alongside the operator — where the plugin must run — so the existing helm upgrade in install-platform.sh brings it up; no separate apply step. The plugin is idle until a Cluster opts in, so installing it changes nothing about backups.

2. Flag-gated cutover templating (…backup.plugin.enabled, default false) for both CNPG clusters (tuist + tuist-ops). Off = the existing in-tree barmanObjectStore, unchanged. On = an ObjectStore CR (same bucket/creds/wal/data, retention moved onto it) + Cluster.spec.plugins + ScheduledBackup method: plugin, with serverName pinned to the cluster name so the plugin continues the existing archive prefix.

3. Docs. README upgrade-path section rewritten to current state (operator 1.29.1; no catch-up history), plus the plugin install + cutover runbook.

Why split install from enable

The flag-on deploy renders kind: ObjectStore; if the plugin’s CRD isn’t present yet, that deploy fails. So the plugin must be installed everywhere first. Shipping the install ahead of any flag flip removes that ordering hazard and is safe (idle until referenced).

Rollout plan (after this merges)

1. Merge this → plugin installed on all envs, backups unchanged.
2. Flip canary (plugin.enabled: true in values-managed-canary.yaml, separate PR). Then verify on canary that WAL archiving continues to the same s3://…/<serverName> path with no errors and pg_wal isn’t piling up.
3. Flip prod + staging once canary is confirmed, and run a restore drill from a plugin-written backup.

Reversible the whole way: flip the flag back and in-tree archiving resumes (in-tree still works on 1.29). Canary first, not all-at-once, specifically to avoid a silent WAL-archiving break reaching prod (the failure mode behind a prior incident: archiving stalls -> pg_wal fills -> Postgres won’t start).

Validation

• Plugin install: helm template renders the plugin-barman-cloud chart cleanly as a subchart of platform — no cnpg-system hardcodes, lands in the release namespace, and its resources are release-prefixed, so it co-locates with the operator without the cross-release conflict in charts#792 (which is about two separate Helm releases). On a brand-new cluster the plugin’s cert-manager Certificate and cert-manager itself apply in the same upgrade; install-platform.sh is idempotent and re-runs every deploy, so any first-pass ordering blip self-heals (our existing clusters already run cert-manager, so it is a non-issue there).
• helm template renders both charts in both flag states (off = unchanged in-tree; on = plugins + ObjectStore + method: plugin).
• Default-off + idle plugin = no rendered backup change on either cluster on merge.

🤖 Generated with Claude Code

No GitHub comments yet.