[Feature]: Add a flag to add the namespace to the backup cluster name

Is there an existing issue already for this feature request/idea?

[X] I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

What problem is this feature going to solve? Why should it be added?

I have multiple clusters that all have the same name but exist within different namespaces. We do this becuase we have multiple development environments for testing. For instance I have dev1, dev2, dev3 as the name space, all of them have a cluster called "api-data" within them.

We also make use of ArgoCD and Kustomize to provision these resources in K8s.

When provisioning the backup I currently have to create multiple files within kustomize that define the backup location that basically adds the name space as a unique identifier to the path. This results in a massive number of files that basically all contain the following:

spec:
  backup:
    barmanObjectStore:
      destinationPath: s3://psql-backup-storage/devX

I'd like to have a single bucket that contains all the backups. I'd also like to not have to specify a unique path in many files. The uniqueness of the cluster is actually the namespace + the cluster name. Therefore I would like to have a flag that tells the cluster to add the cluster name and namespace to the path when creating the files.

Something like this:

spec:
  backup:
    barmanObjectStore:
      includeNamespace: true
      destinationPath: s3://psql-backup-storage

With the result being s3://psql-backup-storage/<namespace>/<cluster>.

Describe the solution you'd like

I'd like a flag in the barman section that allows me to have the namespace be part of the generated path that is used to write files to the object storage.

Describe alternatives you've considered

Write the base paths manually in kustomize, which generates many many files with very little difference.

Additional context

No response

Backport?

Yes

Are you willing to actively contribute to this feature?

Yes

Code of Conduct

[X] I agree to follow this project's Code of Conduct

cloudnative-pg / cloudnative-pg