Skip to content

fix(cluster): align plugin ObjectStore name to barmanObjectName - #991

Open
danishedb wants to merge 5 commits into
cloudnative-pg:mainfrom
danishedb:dev/975
Open

danishedb wants to merge 5 commits into
cloudnative-pg:mainfrom
danishedb:dev/975

Conversation

@danishedb

Copy link
Copy Markdown
Contributor

The pr fixes the name name: {{ include "cluster.fullname" . }}-backups in barman plugin object store to match the cluster
barmanObjectName,

closes #975
Signed-off-by: danishedb danish.khan@enterprisedb.com

Signed-off-by: danishedb <danish.khan@enterprisedb.com>
@danishedb
danishedb requested a review from a team as a code owner August 27, 2026 07:29
@dosubot dosubot Bot added size:XS This PR changes 0-9 lines, ignoring generated files. chart( cluster ) Related to the cluster chart labels Aug 27, 2026
@hh24k

hh24k commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

@danishedb the default-name expression now lives in both cluster.yaml and backup-objectstore.yaml, Would you consider moving it into a helper so both files share one source of truth?

Signed-off-by: danishedb <danish.khan@enterprisedb.com>
@danishedb

Copy link
Copy Markdown
Contributor Author

I have performed following testing to ensure we donnot break anything on existing clusters.

Scenario 1 — defaults (no barmanObjectName set):

Tested: upgrading a running cluster to this PR has no impact — same ObjectStore name, no Cluster spec change, no pod restart, WAL archiving and backups uninterrupted.

Scenario 2 — user sets barmanObjectName (the bug this PR fixes):

Tested : on the released chart this config deadlocks the cluster entirely — the ObjectStore is created under the hardcoded -backups name while the Cluster references the custom name, which never exists. After upgrading to this PR the referenced ObjectStore is created and the cluster bootstraps with working archiving and backups (fresh installs work the same way).

Scenario 3 — user sets barmanObjectName and pre-creates their own ObjectStore with that name:

Tested : the upgrade silently replaces the ObjectStore, re-targeting WALs and cutting retention with no alert — so I Am proposing to add backups.objectStore.create (default true) which, verified by test, leaves the self-managed ObjectStore completely untouched when set to false.

I will push the change for this backups.objectStore.create

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

chart( cluster ) Related to the cluster chart size:XS This PR changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix ObjectStore name in the cluster chart

3 participants