Upgrading Rabbitmq version and operator version in cluster

[paywagh11]

I have deployed a 3 node Rabbitmq cluster and 2 operators ( RMQ cluster kubernetes operator and messaging topology operator) in Azure kubernetes services using manifests one by one.

I need to upgrade the Rabbitmq version and operator version.

How could I perform upgrading in this using manifest files? Should I delete all the previous pods (manifest files) and apply the new version manifest files?

[mkuratczyk]

No, if you delete using the old manifest files (kubectl delete -f), you will completely delete the cluster and Operators. It's ok in a CI environment and similar, if you want to just always start fresh with the latest versions, but absolutely not how you want to upgrade production.

For Operators, just apply the new manifest:
https://www.rabbitmq.com/kubernetes/operator/upgrade-operator.html

For RabbitMQ, change the image version (tag).

[philomory]

When upgrading the image version during a rolling restart, how does the operator handle a difference in Erlang versions? I mean, the official docker images for recent RabbitMQ versions are all built with OTP 25, but presumably at some point that will change to OTP 26. Is there any way to have the operator perform a full-stop upgrade (allowing for downtime, but avoiding the data loss you'd get by simply throwing away the cluster entirely and making a new one)?

[mkuratczyk]

We are not aware of any supported upgrade paths that would require a full stop of the cluster. You should be able to:

1. Perform a rolling upgrade to the latest patch release of your current minor
2. Perform a rolling upgrade to the next minor

If the OTP version changes with the new minor, it should still work fine.

In most cases there's nothing special we need to do for this (from what I know, years ago incompatibilities between OTP versions were more common, but I wasn't involved in RabbitMQ back then). The only recent example I can think of where we had to make some accommodations for an OTP version change is the OTP25->26. We introduced forwards-compatibility into 3.11.18, so again - if you first upgrade to the latest 3.11/OTP25 then you should be able to upgrade to 3.12/OTP26 without a full cluster stop.
For reference: #8057