barman plugin upgrade

[alexeyshishkin-edb]

Hi, Team !
It looks like the documentation is missing 'barman plugin upgrade' chapter to address the following questions:

• how to upgrade from barman plugin 0..4.0 to 0.7.0 ?
• is it possible to upgrade from 0.4.0 to 0.7.0 directly or one should use the consecutive upgrade path, like 0.4.0 -> 0.5.0 -> 0.6.0 -> 0.7.0 ?

[dosubot]

There isn't a documented upgrade path or specific migration steps required to move from Barman Cloud plugin 0.4.0 to 0.7.0. The changelogs and release notes for versions 0.5.0, 0.6.0, and 0.7.0 do not mention any breaking changes or requirements for consecutive upgrades, and no user reports or issues indicate problems with direct upgrades between these versions. Based on available information, a direct upgrade from 0.4.0 to 0.7.0 should be possible, but it's best practice to test the upgrade in a staging environment first to ensure compatibility with your workflows and observability integrations source source.

To reply, just mention @dosu.

---

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

[alexeyshishkin-edb]

one more possible question: do we need to perform additional steps after

barman_cloud_version=v0.7.0
curl -LO https://github.com/cloudnative-pg/plugin-barman-cloud/releases/download/$barman_cloud_version/manifest.yaml
kubectl apply -f manifest.yaml

like
kubectl rollout restart deployment -n $oname-system $oname-controller-manager
the upgrade procedure has to be crystal clear

[dosubot]

No, you do not need to run a manual rollout restart after applying the manifest.yaml for the Barman Cloud plugin upgrade. Applying the manifest with kubectl apply -f manifest.yaml automatically triggers the necessary rollout for the barman-cloud deployment in the cnpg-system namespace. The only recommended post-apply step is to verify the rollout status with:

kubectl rollout status deployment -n cnpg-system barman-cloud

If the rollout completes successfully, the upgrade is done—no further steps are required. This procedure is supported by the official installation documentation and the deployment manifest, which uses a standard Kubernetes rollout strategy and does not require extra actions unless the rollout fails or stalls source.

To reply, just mention @dosu.

---

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

[alexeyshishkin-edb]

for consistency the upgrade from 0.4.0 to 0.7.0:

[alexey@wsl2 ~]$ kubectl apply -f manifest.yaml
customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io configured
serviceaccount/plugin-barman-cloud unchanged
role.rbac.authorization.k8s.io/leader-election-role unchanged
clusterrole.rbac.authorization.k8s.io/metrics-auth-role unchanged
clusterrole.rbac.authorization.k8s.io/metrics-reader unchanged
clusterrole.rbac.authorization.k8s.io/objectstore-editor-role unchanged
clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role unchanged
clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud configured
rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding unchanged
clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding unchanged
clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding unchanged
secret/plugin-barman-cloud-7g4226tm68 created
service/barman-cloud unchanged
deployment.apps/barman-cloud configured
certificate.cert-manager.io/barman-cloud-client unchanged
certificate.cert-manager.io/barman-cloud-server unchanged
issuer.cert-manager.io/selfsigned-issuer unchanged

several items have been configured/created

[alexeyshishkin-edb]

No, you do not need to run a manual rollout restart after applying the manifest.yaml for the Barman Cloud plugin upgrade. Applying the manifest with kubectl apply -f manifest.yaml automatically triggers the necessary rollout for the barman-cloud deployment in the cnpg-system namespace. The only recommended post-apply step is to verify the rollout status with:

kubectl rollout status deployment -n cnpg-system barman-cloud
If the rollout completes successfully, the upgrade is done—no further steps are required. This procedure is supported by the official installation documentation and the deployment manifest, which uses a standard Kubernetes rollout strategy and does not require extra actions unless the rollout fails or stalls source.

To reply, just mention @dosu.

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

If I don't use
kubectl rollout restart deployment -n $oname-system $oname-controller-manager
I will see the old version of barman plugin in the output of
kubectl cnpg -n $oname-system status $cluster_name

[dosubot]

You're correct—after upgrading the Barman Cloud plugin with kubectl apply -f manifest.yaml, the new version is deployed, but the CloudNativePG operator (controller-manager) does not dynamically detect plugin changes. The operator only discovers plugins at startup, so if you don't restart the controller-manager deployment, kubectl cnpg status will continue to show the old plugin version even though the new plugin is running. To ensure the status output reflects the updated plugin version, you do need to run:

kubectl rollout restart deployment -n $oname-system $oname-controller-manager

This behavior is confirmed in the CloudNativePG documentation and code: the operator must be restarted to detect new or updated plugins, as it does not reload them dynamically during runtime (source). The official Barman Cloud plugin docs don't mention this step, but practical experience and the operator's design require it for accurate version reporting.

To reply, just mention @dosu.

---

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