Conversation
Signed-off-by: danishedb <danish.khan@enterprisedb.com>
|
@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>
|
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 |
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