plugin-barman-cloud

mirror of https://github.com/cloudnative-pg/plugin-barman-cloud.git synced 2026-09-05 22:52:19 +02:00

Author	SHA1	Message	Date
Armando Ruocco	0ec8f0db3b	Merge `11469e3ef3` into `77118ed413`	2026-08-24 09:37:36 +02:00
Marco Nenciarini	11469e3ef3	fix: stop keeping the sidecar forever on recovery-only clusters A cluster bootstrapped only via RecoveryBarmanObjectName, with no continuing archiving or replica source, only ever needs the sidecar for its one-time bootstrap restore. Gate its injection on cluster.Status.CurrentPrimary being unset, so it stops being added once that instance is up. CurrentPrimary is set by the instance manager itself, from inside the primary pod, only once it has completed its own bootstrap - unlike cluster.Status.Instances / IsInitialized(), which flips as soon as the instance's PVC exists, well before the pod is even created. Gating on IsInitialized() would mean the sidecar is never added to the one pod that needs it to perform its restore. Once CurrentPrimary is set, this makes the operator's own drift-check see the already-running pod's spec as outdated and roll it out to drop the sidecar. That is deliberately accepted rather than engineered around: it is one deterministic rollout using the same machinery the operator already uses for every other pod-spec change (a switchover if a replica is available, an in-place restart otherwise), not a new or fragile risk. Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>	2026-08-24 09:37:34 +02:00
Marco Nenciarini	a07a396c4f	refactor: deduplicate barman object store presence check Validate() and the instance sidecar injection condition each independently re-encoded "is any of BarmanObjectName, RecoveryBarmanObjectName or ReplicaSourceBarmanObjectName set". The injection condition had already drifted from Validate() once, missing RecoveryBarmanObjectName until this PR added it back. Extract a single HasAnyBarmanObjectStore() method so the two checks can no longer drift apart the same way again. Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>	2026-08-24 09:37:34 +02:00
Armando Ruocco	510015c15c	feat: serve restore hooks from the instance sidecar The bootstrap that used to run in a dedicated recovery Job now happens in-process inside the instance pod before PostgreSQL starts, so the sidecar shipped in that pod must answer the same Restore RPC the operator sends over the plugin sockets. The instance mode now registers the restore job hooks and advertises the restore-job service capability so the operator can reach them. A cluster that only bootstraps from an object store, without continued archiving, previously received no sidecar in its instance pods; the injection condition is widened to match what the plugin configuration already considers valid, so those clusters get the sidecar too. Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>	2026-08-24 09:37:34 +02:00

1 changed files with 1 additions and 1 deletions

									
										2

Taskfile.yml
									
										View File
										
				@ -23,7 +23,7 @@ tasks:

				      # renovate: datasource=git-refs depName=golangci-lint lookupName=https://github.com/sagikazarmark/daggerverse currentValue=main

				      DAGGER_GOLANGCI_LINT_SHA: ff27cd50f6b4eed2e3753c520632cd6099e1ce52

				      # renovate: datasource=docker depName=golangci/golangci-lint versioning=semver

				      GOLANGCI_LINT_VERSION: v2.13.1

				      GOLANGCI_LINT_VERSION: v2.12.2

				    cmds:

				      - >

				        GITHUB_REF= dagger -sc "github.com/sagikazarmark/daggerverse/golangci-lint@${DAGGER_GOLANGCI_LINT_SHA}

Compare commits

4 Commits

0af80b7091 ... 0ec8f0db3b

2

Taskfile.yml

View File

Compare commits

4 Commits 0af80b7091 ... 0ec8f0db3b

2 Taskfile.yml Unescape Escape View File

4 Commits

0af80b7091 ... 0ec8f0db3b

2

Taskfile.yml

View File