Rabbit MQ + Kubernetes upgrade process

[Neil Thomas]

Hi all,

I'm working on a solution that uses the Rabbit MQ operator to deploy a Rabbit MQ cluster in Kubernetes. I'm trying to understand the steps required when upgrading the Rabbit MQ operator. The docs say:

"Upgrading the cluster-operator to this version will update RabbitMQ clusters (i.e. will cause rolling update of the underlying StatefulSets)."

i.e. executing 'kubectl apply', referring to the updated cluster-operator.yml should update all the Rabbit MQ clusters (unless the cluster has explicitly paused reconciliation).

However, when I apply the updated cluster operator yaml, I see the Rabbit MQ operator pod updating as expected, but the two pods in my cluster don't seem to be updated. Is there an expected delay between the operator being upgraded and the clusters being upgraded? Or, am I missing a step?

Thanks,

Neil

[Michal Kuratczyk]

Hi,

There are two aspects of a RabbitMQ deployment update: changing the version of RabbitMQ (image) and changing other aspects of the deployment. RabbitMQ version (image property) is not changed automatically - you need to do this manually after upgrading the Operator.

This comment refers to the other aspects. For example, in 1.4.0 we split the configuration into conf.d - rather than merging the defaults generated by the Operator with user-provided configuration and then storing everything in one ConfigMap key and mounting it as a single file, we switched to mounting them separately into /etc/rabbitmq/conf.d. This change requires changes to the StatefulSet definition that happen on the next reconciliation of the cluster. This leads to a rolling restart of the cluster, even though the version remains unchanged.

If you want to avoid multiple restarts, you can pause reconciliation, update the Operator, change the image property and then resume reconciliation. This way, one StatefulSet update will upgrade RabbitMQ and all resources necessary, such as ConfigMaps and the StatefulSet.

Best,

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/7e510b25-52de-4b67-a6cb-80df988c26b1n%40googlegroups.com.

--

Michał

RabbitMQ team

[Neil Thomas]

Hi Michal,

Many thanks for your reply. Can you confirm exactly how to set the image property such that the Rabbit MQ version will be updated? Is this set in the .yaml descriptor for the cluster itself? I've not seen anything in the docs that mention explicitly setting this.

Thanks,

Neil

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/CAA81d0sVhW4%2BCSXYhwd9p1PfX8tBXiscQYDCBPMfiX8xAmeM6Q%40mail.gmail.com.

[Michal Kuratczyk]

It's a Kubernetes resource like any other so you change it your preferred way: for testing you can `kubectl edit rabbitmqcluster ...`, for a slightly more advanced option edit the YAML file and `kubectl apply`, you can use any YAML templating tool, CI/CD/GitOps process you want. The Operator only cares that that RabbitmqCluster resource in your Kubernetes cluster changes and it will update the StatefulSet accordingly.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/CAAW5FFDCADqx%2BKr%2BvRQJNFr7qt9itx1R_kE_%2BtDQv8idVV0bpQ%40mail.gmail.com.

--

Michał

RabbitMQ team