Skip to content

v0.7.md

Latest commit

 

History

History
66 lines (48 loc) · 2.78 KB

v0.7.md

File metadata and controls

66 lines (48 loc) · 2.78 KB
Raw

Release Notes: v0.7.x

Operator-facing upgrade notes for the v0.7 series, newest first. See the Release Notes index for how to read these pages.

Changes that have merged to main but are not yet in a tagged release are on the Unreleased page.

v0.7.0 — released 2026-10-26

Action required

RabbitMQ is now 4.2.9. RabbitMQ does not enable the feature flags a new version introduces on its own, and the cluster-operator only does so when autoEnableAllFeatureFlags is set on the RabbitmqCluster, which UnderStack does not set. After the upgrade the rabbitmq_4.0.0, rabbitmq_4.1.0, rabbitmq_4.2.0 and khepri_db flags are left disabled until you enable them. Nothing breaks while they stay disabled, but RabbitMQ will refuse a later upgrade to the next minor version until they are on.

Wait until every member of the cluster is running 4.2.9, then enable the flags from any one node:

  1. Confirm all members have rolled and are healthy. Every pod should be Ready and every node should report 4.2.9:

    kubectl -n openstack get pods -l app.kubernetes.io/name=rabbitmq
kubectl -n openstack exec rabbitmq-server-0 -c rabbitmq -- \
    rabbitmq-diagnostics cluster_status

  2. Enable the flags. Feature flags are cluster-wide, so run this once:

    kubectl -n openstack exec rabbitmq-server-0 -c rabbitmq -- \
    rabbitmqctl enable_feature_flag all

  3. Confirm the flags you expect are on:

    kubectl -n openstack exec rabbitmq-server-0 -c rabbitmq -- \
    rabbitmqctl list_feature_flags

    rabbitmq_4.0.0, rabbitmq_4.1.0, rabbitmq_4.2.0 and khepri_db should report enabled. Investigate any of them that is still disabled before moving on.

  4. Check that the cluster is still healthy. It should list all three nodes as running, with no alarms and no network partitions:

    kubectl -n openstack exec rabbitmq-server-0 -c rabbitmq -- \
    rabbitmq-diagnostics cluster_status