fix(ha-restore-test): load barman-cloud plugin without WAL archiver so restored PG starts (REN-339) #1063

2026-09-28T17:02:48Z

Ghost commented

2026-09-28 17:02:48 +00:00

What: ha-restore-test/cluster.yaml gets a plugins: entry for barman-cloud with isWALArchiver: false, barmanObjectName: ha-pg-store-ro, serverName: ha-pg-restore-test. Comments updated.

Why: After #1061 the full-recovery Job completed (16:50Z), but instance ha-pg-restore-1 never starts PostgreSQL. The instance manager logs Error loading plugins ... Unknown plugin: barman-cloud.cloudnative-pg.io in a loop, and the startup probe returns 500. The Cluster references the plugin via externalClusters, but CNPG only injects the sidecar for spec.plugins.

Safety: isWALArchiver: false means no WAL archiving. There is no Backup or ScheduledBackup in the namespace, so no base backups, and there is no retentionPolicy on the ObjectStore, so nothing is pruned. The distinct serverName is a second guard against touching ha-pg/ha-pg. The change is limited to namespace ha-restore-test and nothing in home-assistant changes. The pod rolls, and it is a throwaway pod.

Verified: read-only cluster logs and events (above). YAML is only lint-checked locally.

Revert: revert this commit. The instance goes back to being stuck, with no effect on prod.

🤖 Generated with Claude Code

**What:** `ha-restore-test/cluster.yaml` gets a `plugins:` entry for barman-cloud with `isWALArchiver: false`, `barmanObjectName: ha-pg-store-ro`, `serverName: ha-pg-restore-test`. Comments updated. **Why:** After #1061 the full-recovery Job completed (16:50Z), but instance `ha-pg-restore-1` never starts PostgreSQL. The instance manager logs `Error loading plugins ... Unknown plugin: barman-cloud.cloudnative-pg.io` in a loop, and the startup probe returns 500. The Cluster references the plugin via `externalClusters`, but CNPG only injects the sidecar for `spec.plugins`. **Safety:** `isWALArchiver: false` means no WAL archiving. There is no Backup or ScheduledBackup in the namespace, so no base backups, and there is no retentionPolicy on the ObjectStore, so nothing is pruned. The distinct serverName is a second guard against touching `ha-pg/ha-pg`. The change is limited to namespace `ha-restore-test` and nothing in `home-assistant` changes. The pod rolls, and it is a throwaway pod. **Verified:** read-only cluster logs and events (above). YAML is only lint-checked locally. **Revert:** revert this commit. The instance goes back to being stuck, with no effect on prod. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Ghost added 1 commit 2026-09-28 17:02:48 +00:00

fix(ha-restore-test): load barman-cloud plugin (no WAL archiver) so the restored instance starts (REN-339)

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

e2705ba0fb

The instance manager refuses to start PostgreSQL when the Cluster references
a plugin (externalClusters) that has no sidecar in the pod. Add a plugins
entry with isWALArchiver: false and a distinct serverName.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Ghost approved these changes

2026-09-28 17:03:53 +00:00

Ghost left a comment

Approved at e2705ba0fb. Checked: diff touches only kubernetes/apps/ha-restore-test/{cluster,objectstore}.yaml; ha-pg-restore-1 postgres log loops 'Unknown plugin: barman-cloud.cloudnative-pg.io' (17:01:57Z); CNPG operator 1.30.1 + plugin-barman-cloud v0.15.0 support plugins[].isWALArchiver; isWALArchiver false + no Backup/ScheduledBackup + serverName ha-pg-restore-test (ha-pg uses default serverName ha-pg, isWALArchiver true, store ha-pg-store in home-assistant) so no writes to ha-pg's prefix. Revert = revert commit, no prod effect.

Approved at e2705ba0fb5a3980bfeb63d910debbefd03f6876. Checked: diff touches only kubernetes/apps/ha-restore-test/{cluster,objectstore}.yaml; ha-pg-restore-1 postgres log loops 'Unknown plugin: barman-cloud.cloudnative-pg.io' (17:01:57Z); CNPG operator 1.30.1 + plugin-barman-cloud v0.15.0 support plugins[].isWALArchiver; isWALArchiver false + no Backup/ScheduledBackup + serverName ha-pg-restore-test (ha-pg uses default serverName ha-pg, isWALArchiver true, store ha-pg-store in home-assistant) so no writes to ha-pg's prefix. Revert = revert commit, no prod effect.

Ghost merged commit 14b248b1a4 into master

2026-09-28 17:04:07 +00:00

Ghost referenced this issue from a commit

2026-09-28 17:04:08 +00:00

Merge pull request 'fix(ha-restore-test): load barman-cloud plugin without WAL archiver so restored PG starts (REN-339)' (#1063) from atlas/ren-339-restore-plugin into master

review-bot reviewed

2026-09-28 17:05:38 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit e2705ba0fb5a3980bfeb63d910debbefd03f6876.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Adds a spec.plugins entry (barman-cloud.cloudnative-pg.io, isWALArchiver: false, barmanObjectName: ha-pg-store-ro, serverName: ha-pg-restore-test) to kubernetes/apps/ha-restore-test/cluster.yaml so CNPG injects the instance-manager sidecar the pre-existing externalClusters recovery source needs. Comments in cluster.yaml and objectstore.yaml are updated to match. The change is small, well-scoped to the throwaway ha-restore-test namespace, and I found no blocking issues.

The exact mechanism — declaring spec.plugins with isWALArchiver: false purely to get the sidecar loaded for a restore, without turning on archiving — is not new to this repo: it's already documented and described as verified 2026-07-25 on im-pg in kubernetes/RECOVERY.md:166-217 ("CNPG restore-test" runbook), including the identical failure mode this PR fixes ("Unknown plugin: barman-cloud.cloudnative-pg.io"). That existing, independently-verified precedent is good corroboration that the fix is correct, not just plausible.

I checked the specifics that would make this unsafe and they hold up:

barmanObjectName: ha-pg-store-ro correctly matches the ObjectStore named ha-pg-store-ro in the same namespace (kubernetes/apps/ha-restore-test/objectstore.yaml:12).
There is genuinely no Backup/ScheduledBackup resource in ha-restore-test/ (confirmed via directory listing) and no retentionPolicy on the ObjectStore, so nothing can write or prune against ha-pg's real backup prefix even with the sidecar loaded — matching the PR body's safety claims.
serverName: ha-pg-restore-test is distinct from the live serverName: ha-pg used by the pre-existing externalClusters entry (which correctly still points recovery at the real ha-pg server path) — a real, if inert, second guard against collision.
Egress: ha-restore-test/network-policy.yaml only restricts ingress for cnpg.io/cluster: ha-pg-restore pods; no policy selects that label for egress, so Cilium's default-allow applies and the new sidecar can still reach the S3 endpoint — no network-policy update is needed for this change.

Tests

No automated test accompanies this (it's a GitOps manifest change), consistent with how this repo handles such fixes. ha-restore-test/pg-check-job.yaml and config-check-job.yaml already exist in this namespace and will exercise the fix in practice (the instance actually starting and becoming queryable) once applied. The PR body documents the read-only log/event verification already performed for the underlying bug. No further test is warranted for a manifest change like this.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `e2705ba0fb5a3980bfeb63d910debbefd03f6876`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Adds a `spec.plugins` entry (`barman-cloud.cloudnative-pg.io`, `isWALArchiver: false`, `barmanObjectName: ha-pg-store-ro`, `serverName: ha-pg-restore-test`) to `kubernetes/apps/ha-restore-test/cluster.yaml` so CNPG injects the instance-manager sidecar the pre-existing `externalClusters` recovery source needs. Comments in `cluster.yaml` and `objectstore.yaml` are updated to match. The change is small, well-scoped to the throwaway `ha-restore-test` namespace, and I found no blocking issues. The exact mechanism — declaring `spec.plugins` with `isWALArchiver: false` purely to get the sidecar loaded for a restore, without turning on archiving — is not new to this repo: it's already documented and described as *verified 2026-07-25 on im-pg* in `kubernetes/RECOVERY.md:166-217` ("CNPG restore-test" runbook), including the identical failure mode this PR fixes ("Unknown plugin: barman-cloud.cloudnative-pg.io"). That existing, independently-verified precedent is good corroboration that the fix is correct, not just plausible. I checked the specifics that would make this unsafe and they hold up: - `barmanObjectName: ha-pg-store-ro` correctly matches the `ObjectStore` named `ha-pg-store-ro` in the same namespace (`kubernetes/apps/ha-restore-test/objectstore.yaml:12`). - There is genuinely no `Backup`/`ScheduledBackup` resource in `ha-restore-test/` (confirmed via directory listing) and no `retentionPolicy` on the `ObjectStore`, so nothing can write or prune against `ha-pg`'s real backup prefix even with the sidecar loaded — matching the PR body's safety claims. - `serverName: ha-pg-restore-test` is distinct from the live `serverName: ha-pg` used by the pre-existing `externalClusters` entry (which correctly still points recovery at the real `ha-pg` server path) — a real, if inert, second guard against collision. - Egress: `ha-restore-test/network-policy.yaml` only restricts *ingress* for `cnpg.io/cluster: ha-pg-restore` pods; no policy selects that label for egress, so Cilium's default-allow applies and the new sidecar can still reach the S3 endpoint — no network-policy update is needed for this change. ## Tests No automated test accompanies this (it's a GitOps manifest change), consistent with how this repo handles such fixes. `ha-restore-test/pg-check-job.yaml` and `config-check-job.yaml` already exist in this namespace and will exercise the fix in practice (the instance actually starting and becoming queryable) once applied. The PR body documents the read-only log/event verification already performed for the underlying bug. No further test is warranted for a manifest change like this. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

alert-monitor-bot referenced this pull request

2026-09-28 17:16:20 +00:00

[alert] KubePodNotReady (ha-restore-test) #1064

Ghost referenced this issue from a commit

2026-09-28 17:25:22 +00:00

fix(ha-restore-test): recreate recovered cluster as ha-pg-restore-2 so it starts with the plugin sidecar (REN-339)

Ghost referenced this pull request

2026-09-28 17:25:29 +00:00

fix(ha-restore-test): recreate recovered cluster as ha-pg-restore-2 (REN-339) #1065

issue-fix-bot referenced this pull request

2026-09-28 17:42:43 +00:00

[alert] KubePodNotReady (ha-restore-test) #1064