feat(cluster): add CNPG-I plugin support with ObjectStore CRD

[bernardgut]

Description

Add support for CNPG-I plugins in the cluster chart. This is a reworked version of #680 that addresses all reviewer feedback.

Changes

• cluster.plugins passthrough to Cluster spec with auto-injection of barmanObjectName
• Automatic ObjectStore CRD generation when barman-cloud.cloudnative-pg.io plugin is enabled
• Plugin-based ScheduledBackup with pluginConfiguration, automatically uses method: plugin unless volumeSnapshot is explicitly set
• Plugin-based recovery from object_store using the plugin external cluster source
• Conditional rendering: legacy barmanObjectStore only rendered when plugin is absent (no regression for existing users)

Reviewer feedback addressed from #680

Feedback (from @ProbstDJakob)	Fix
enabled required but CRD defaults to true	Helper treats enabled as true when omitted
ObjectStore name / plugin barmanObjectName coupling	Auto-derived and auto-injected into Cluster plugin parameters
ScheduledBackup method forcibly overridden to plugin	Only overrides when method is not explicitly volumeSnapshot
Mixed indent/nindent in recovery template	Normalized indentation throughout

Testing

Template validation

• helm template with default values produces identical output to stock chart (zero regression)
• Plugin-enabled config generates valid ObjectStore + Cluster with plugins + plugin ScheduledBackup
• volumeSnapshot method preserved when explicitly set
• Test assertions updated in postgresql-cluster-configuration

E2E on KIND (k8s v1.35.0)

Full stack: CNPG operator v1.28.1, cert-manager v1.17.2, MinIO operator + tenant, barman-cloud plugin v0.11.0.

• ✅ ObjectStore CRD created and accepted by the API server
• ✅ Cluster with plugins section applied — operator registers the plugin
• ✅ Sidecar container injected into PostgreSQL pod (2/2 Running, image plugin-barman-cloud-sidecar:v0.11.0)
• ✅ Data written to database (4 rows)
• ✅ Plugin-based Backup completed successfully (method: plugin)

Files changed (11)

File	Change
_helpers.tpl	Added useBarmanCloudPlugin and barmanCloudObjectStoreName helpers
cluster.yaml	Plugin passthrough with auto-injected barmanObjectName
objectStore.yaml	New — ObjectStore CRD template
_backup.tpl	Conditional legacy barmanObjectStore
_external_clusters.tpl	Plugin-based recovery source
scheduled-backups.yaml	Conditional plugin method
values.yaml	plugins: [] with docs
values.schema.json	Plugins schema
README.md	Values table entry
test/*	Plugin assertion in non-default config test

Closes #634
Ref: #680

[bernardgut]

Ok I think this is ready for review.:

Tested the full plugin-based backup flow end-to-end on a local KIND cluster (k8s v1.35.0):

Stack deployed:

• CNPG operator v1.28.1
• cert-manager v1.17.2
• MinIO operator + tenant (S3-compatible storage)
• barman-cloud plugin v0.11.0

Test steps:

1. Deployed a standalone cluster with plugins: [{name: barman-cloud.cloudnative-pg.io, isWALArchiver: true}] and backups enabled against MinIO
2. Verified the chart generates a valid ObjectStore CRD (accepted by the API server)
3. Verified the Cluster spec includes parameters.barmanObjectName auto-linked to the ObjectStore
4. Confirmed the barman-cloud sidecar was injected into the PostgreSQL pod (2/2 Running, image plugin-barman-cloud-sidecar:v0.11.0)
5. Wrote test data (4 rows)
6. Triggered a Backup with method: plugin and pluginConfiguration.name: barman-cloud.cloudnative-pg.io
7. Backup completed successfully in ~3 seconds

Template-level validation:

• Default values → identical output to stock chart (zero regression)
• Plugin config → correct ObjectStore, ScheduledBackup with method: plugin, and pluginConfiguration
• volumeSnapshot method preserved when explicitly set

[pha91]

Thx for the rework :) i'm going to close my pr sine it is outdated anyway.
@sxd maybe you could also have a look here?

[leoarry]

Thanks for this work, extremely appreciated :).
I just have few outstanding questions:

• As mentioned already on previous PR comment when using s3 compatible storage sometimes there is the needs to force some s3 client settings through env vars in order to work, would be nice to be able to set env vars for the instanceSidecarConfiguration spec of the ObjectStore CR imo.
• Sometimes may want to set annotations to avoid helm/argocd accidental deleting of the resources, would be nice to be able to add the cluster annotations to the ObjectStore CR imo (similar to what Database CR does already essentially).
• How recovery form S3 are going to be handled? previously there was the possibility to specify 3 different sets of object store settings (one for backup, one for recovery and one for replica) so technically you were able to use the same value file to define the backup and restore destinations, is this functionality dropped now?

[bernardgut]

Thanks for the thorough review @leoarry! I've addressed your feedback points in the latest force-push:

1. instanceSidecarConfiguration env vars — ✅ Done. The chart now exposes backups.instanceSidecarConfiguration as a passthrough to the ObjectStore CRD spec.instanceSidecarConfiguration. This covers the S3-compatible storage use case mentioned by @canaykin on #680. Example:

backups:
  instanceSidecarConfiguration:
    env:
      - name: AWS_REQUEST_CHECKSUM_CALCULATION
        value: when_required
      - name: AWS_RESPONSE_CHECKSUM_VALIDATION
        value: when_required

2. Annotations on ObjectStore CR — ✅ Done. The ObjectStore CR now inherits cluster.annotations and cluster.additionalLabels, mirroring the existing pattern from databases.yaml. This ensures Helm/ArgoCD resource-policy annotations and custom labels work correctly.

3. Recovery from separate S3 sources — The current PR supports plugin-based recovery via mode: recovery + method: object_store, which points the external cluster to the backup ObjectStore through the plugin interface. This works for the common case of restoring from your own backups (tested E2E : backup + full recovery with data verification).

For the use case of specifying independent ObjectStore configurations for recovery and replica (different buckets, credentials, etc.), this would require generating multiple ObjectStore CRDs and expanding the values API. I think that's best handled as a follow-up PR to keep this one focused. I'll open a tracking issue for it. In the meantime, the legacy barmanObjectStore path for recovery and replica remains fully functional for users not using the plugin.

Re-tested E2E on k8s with CNPG v1.28.1, barman-cloud plugin v0.11.0, cert-manager v1.17.2, MinIO:

• ✅ ObjectStore CRD created with annotations + env vars
• ✅ Sidecar injected (2/2 Running, plugin-barman-cloud-sidecar:v0.11.0)
• ✅ Plugin-based backup completed successfully (method: plugin)
• ✅ Plugin-based recovery from object_store — all data verified

[bernardgut]

Follow-up push — API quality improvements:

1. DRY plugin name helper — Extracted the hardcoded string barman-cloud.cloudnative-pg.io (previously duplicated across 5 template files) into a single canonical helper template cluster.barmanCloudPluginName. All templates now reference it via {{ include "cluster.barmanCloudPluginName" . }}. This makes the plugin name a single point of change.

2. Documented method silent override — Added a clarifying comment to values.yaml explaining that when the barman-cloud plugin is enabled, scheduledBackups[].method: barmanObjectStore is automatically upgraded to plugin. Use volumeSnapshot to bypass the plugin.

3. Regenerated README — Updated charts/cluster/README.md via helm-docs to document the new backups.instanceSidecarConfiguration value.

All changes verified via helm template (default + plugin-enabled rendering) and live deployment (kubectl get confirming plugin name resolves correctly in ObjectStore, Cluster, and ScheduledBackup CRDs).

[leoarry]

@bernardgut you're an absolute legend!
Thanks a lot for your effort!

[kernelb00t]

Hello maintainers! I'm building my cluster with the new Barman Cloud plugin, and I would like to know how much time approx. would this code be released. How does this project triggers releases? Do you have an idea of a potential release date, and if this would include this PR?

Also, I take the opportunity to ask a question:
I have an S3-compatible server (Garage) hosted separately in the LAN of the cluster, so to use it I would specify http://192.168.1.XXX:3900 as the endpointURL. I make Garage use path style to access the buckets (obviously <bucket>.server.com would not work with an IP), is it compatible or should I use the host style to specify buckets?

Thank you for your time!

[centaurea-riba]