RHEL10: migrate rabbitmq clusters to rhel10 #13383

New issue

Open

opened 2026-06-01 21:56:32 +00:00 by kevin · 3 comments

kevin commented

2026-06-01 21:56:32 +00:00

Owner

Description of request

We should look at migrating our rhel9 rabbitmq clusters to rhel10.

We will need to make sure there's a version of rabbitmq-server available in the centos messaging sig and hopefully it's not to incompatible.

### Description of request We should look at migrating our rhel9 rabbitmq clusters to rhel10. We will need to make sure there's a version of rabbitmq-server available in the centos messaging sig and hopefully it's not to incompatible.

kevin referenced this issue

2026-06-01 21:57:06 +00:00

RHEL10 adoption #12712

smoliicek added the

points

Priority

Low

labels

2026-06-02 19:09:25 +00:00

abompard commented

2026-08-11 17:16:36 +00:00

Member

I've looked at https://www.rabbitmq.com/docs/upgrade and here's the plan I've come up with. It's the longest but it should avoid downtime or message loss.

Current RabbitMQ version: 3.9.21
Current Erlang version: 26.2.5
RabbitMQ versions available in CentOS's monitoring SIG repo: 4.2.7 and 4.2.9
Erlang version available in CentOS's monitoring SIG repo: 26.2.5.21

Versions of RabbitMQ we will be upgrading through: 3.10, 3.11.18, 3.12, 3.13, 4.2.7 (which is compatible with erlang 26 and 27). We will not upgrade to 4.2.9 as it only compatible with erlang 27, not until we've upgraded the host to RHEL10.

Plan

For each version of RabbitMQ we want to be upgrading through:
- For each cluster node
  - on RHEL9 upgrade to RabbitMQ version $VERSION
    - use https://www.rabbitmq.com/docs/install-rpm#dnf-repositories
  - check for alarms in rabbitmq-diagnostics alarms
  - check cluster status in rabbitmq-diagnostics cluster\_status | less -R
- Once all nodes are upgraded to $VERSION, enable all stable feature flags: rabbitmqctl enable_feature_flag all
For each cluster node
- Shut it down, upgrade to RHEL10, bring it back up with RabbitMQ 4.2.7 from the CentOS messaging SIG
- check for alarms in rabbitmq-diagnostics alarms
- check cluster status in rabbitmq-diagnostics cluster\_status | less -R

I would recommend against upgrading to the 4.2.9 version provided by the CentOS Messaging SIG as RabbitMQ upstream say it's only supported on Erlang 27 and higher, and CentOS only provides Erlang 26 for now.

This theoretically should work. (not a chance it'll actually work without fiddling). I can start doing this on staging.

I've looked at https://www.rabbitmq.com/docs/upgrade and here's the plan I've come up with. It's the longest but it should avoid downtime or message loss. Current RabbitMQ version: 3.9.21 Current Erlang version: 26.2.5 RabbitMQ versions available in [CentOS's monitoring SIG repo](https://buildlogs.centos.org/centos/10-stream/messaging/x86_64/rabbitmq-4/Packages/r/): 4.2.7 and 4.2.9 Erlang version available in [CentOS's monitoring SIG repo](https://buildlogs.centos.org/centos/10-stream/messaging/x86_64/rabbitmq-4/Packages/e/): 26.2.5.21 Versions of RabbitMQ we will be upgrading through: 3.10, 3.11.18, 3.12, 3.13, 4.2.7 (which is compatible with erlang 26 and 27). We will not upgrade to 4.2.9 as it [only compatible with erlang 27](https://www.rabbitmq.com/docs/which-erlang), not until we've upgraded the host to RHEL10. ### Plan - For each version of RabbitMQ we want to be upgrading through: - For each cluster node - on RHEL9 upgrade to RabbitMQ version $VERSION - use https://www.rabbitmq.com/docs/install-rpm#dnf-repositories - check for alarms in `rabbitmq-diagnostics alarms` - check cluster status in `rabbitmq-diagnostics cluster\_status | less -R` - Once all nodes are upgraded to $VERSION, enable all stable feature flags: `rabbitmqctl enable_feature_flag all` - For each cluster node - Shut it down, upgrade to RHEL10, bring it back up with RabbitMQ 4.2.7 from the CentOS messaging SIG - check for alarms in `rabbitmq-diagnostics alarms` - check cluster status in `rabbitmq-diagnostics cluster\_status | less -R` I would recommend against upgrading to the 4.2.9 version provided by the CentOS Messaging SIG as RabbitMQ upstream say it's only supported on Erlang 27 and higher, and CentOS only provides Erlang 26 for now. This **theoretically** should work. (not a chance it'll actually work without fiddling). I can start doing this on staging.