Bug: Installing barman-cloud-plugin will fail if the CloudNativePG operator is installed to a namespace other than cnpg-system

[jansenfuller]

I installed the CNPG operator into the namespace "cnpg" instead of "cnpg-system" using the following helm command

helm install --namespace cnpg --create-namespace --version 0.27.0 cnpg cnpg/cloudnative-pg

The install completed successfully and is being used with two different clusters currently. I then tried to install the Barman Cloud Plugin with the following command

helm install --namespace cnpg --create-namespace plugin-barman-cloud plugin-barman-cloud/cloudnative-pg

The following error was thrown

Error: INSTALLATION FAILED: Unable to continue with install: ConfigMap "cnpg-controller-manager-config" in namespace "cnpg" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "plugin-barman-cloud": current value is "cnpg"    

I'm unsure how to remedy this. Manually changing the annotations works but cannot be done to all of the CRDs and objects. I've tried the following values to possibly override the annotations but I have had no luck.

namesapceOverride: "cnpg"
additionalEnv:
  - name: RELEASE_NAME
  - value: "cnpg"

Help would be appreciated.

[dosubot]

Hi @jansenfuller! I'm Dosu and I’m helping the charts team.

This error happens because Helm tracks resource ownership using annotations, and both the operator and the plugin charts try to manage the same ConfigMap (cnpg-controller-manager-config) in the same namespace. Helm won't let a second release take ownership of a resource already managed by another release, which is why you see the annotation validation error.

The Barman Cloud Plugin must be installed in the same namespace as the CloudNativePG operator, and only one Helm release should manage shared resources like this ConfigMap in that namespace. The namespaceOverride and additionalEnv values don't resolve this, because they don't change Helm's ownership model or the fact that the resource is already owned by the operator release (docs).

There isn't a supported way to override or merge ownership for shared resources via chart values. Manual annotation changes are not scalable or recommended. The best practice is to install both the operator and the plugin in the same namespace, using a single Helm release to manage shared resources. If you need to upgrade to newer plugin versions, follow the Resource Name Migration Guide to clean up old resources and avoid naming conflicts (PR #593).

If you want to keep using Helm for both, ensure only one release manages the shared ConfigMap, or consider deploying the plugin using manifests instead of Helm to avoid the ownership conflict.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[jansenfuller]

If the Barman Cloud Plugin and CNPG operator are supposed to be installed as one release, how is that done? Even when I run the following helm install command I get another failure

helm install --namespace cnpg cnpg cloudnative-pg/plugin-barman-cloud

with the output

Error: INSTALLATION FAILED: unable to continue with install: CustomResourceDefinition "objectstores.barmancloud.cnpg.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "cnpg"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "cnpg"

[dosubot]

The Barman Cloud Plugin and CNPG operator are not meant to be installed as a single Helm release. The error you’re seeing happens because Helm tracks ownership of cluster-scoped resources like CRDs, and only one release can manage each CRD. When you try to install both together, Helm detects that the CRD already exists (or is managed by another release) and fails with an ownership metadata error reference.

The supported approach is to install the operator (via Helm) and the plugin (via Helm or manifests) as separate releases. Then, configure your Cluster resource to use the plugin by adding it to the .spec.plugins section and referencing the appropriate ObjectStore. Here’s an example:

spec:
  plugins:
    - name: barman-cloud.cloudnative-pg.io
      isWALArchiver: true
      parameters:
        barmanObjectName: my-objectstore

There is no supported way to combine the operator and plugin into a single Helm release, and doing so will always result in Helm ownership conflicts for CRDs and other shared resources reference.

If you want to use the plugin, install it separately and integrate it via your Cluster spec. This is the recommended and documented workflow.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[jansenfuller]

But I can't install the plugin as a separate release because of the aforementioned error, saying the release annotations don't match for the ConfigMaps

[dosubot]

This is a limitation of how Helm tracks resource ownership: only one Helm release can manage a given resource like the cnpg-controller-manager-config ConfigMap in a namespace. When you install the operator with Helm, it "owns" that ConfigMap, so a second Helm release (the plugin) can't take ownership—hence the annotation error. There's no supported way to override this or merge ownership via chart values, and manual annotation changes aren't scalable or safe for all resources.

The recommended approach is to install the operator and the plugin in the same namespace, but only have one Helm release manage shared resources. If you need both, use Helm for the operator and install the plugin using manifests (kubectl apply) instead of Helm to avoid the conflict. The current Helm charts don't support combining the operator and plugin into a single release or managing shared resources across releases without these errors. For plugin-based backups, follow the manual setup described in the plugin documentation and migration guide (charts issue #629, charts issue #443).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[jansenfuller]

Okay then what would those manifests look like? Where they install the two charts with the same release and namespace but in different manifests.

On top of that, that reiterates my previous issue. If you install the operator in a different namespace (in my case "cnpg" instead of "cnpg-system"), you will not be able to install the plugin as you can't specify the namespace with the install manifest.

[leoarry]

@jansenfuller just a quick question, did you originally install the plugin chart in a different namespace and then try to reinstall it?
Keep in mind that uninstalling a Helm chart does not remove any installed CRDs. You’ll need to delete those manually before reinstalling the chart in the desired namespace.
You can list the existing CRDs with kubectl get crd -o name and delete a specific CRD with kubectl delete crd <crd-name>

[jansenfuller]

No. I had installed the CNPG chart into the cnpg namespace then tried to install the Barman Cloud Plugin into the same namespace. That's when I discovered that you CANNOT use the Helm chart for both CNPG and BCP due to both of them depending on a configmap and Helm not allowing two releases to manage one object.

My solution was use the cnpg-system namespace and to keep using Helm for CNPG installation and then manually installing BCP