Dear Maintainer,
(I'm sorry for the default body template on bug submission. I messed up
when using a container. It didn't have an editor so reportbug
malfunctioned and I though the process was to send the bug title and
metadata from reportbug, and then one could fill the body via email reply)
* What led up to the situation?
I was investigating a failure on rabbitmq-server 4.X on a CI build
testing. Pointing to possibly the packaging needing to create a plugin
directory or having a value for the default related config value.
#15 124.9 Error: :plugins_dir_does_not_exist
#15 124.9 Arguments given:
#15 124.9 enable rabbitmq_stomp
#15 124.9
#15 124.9 Usage
#15 124.9
#15 124.9 rabbitmq-plugins [--node <node>] [--longnames] [--quiet]
enable <plugin1> [ <plugin2>] | --all [--offline] [--online]
Another occurrence of the plugin dir issue on another distro:
https://wiki.archlinux.org/title/Talk:RabbitMQ#Plugins_Directory_Missing
So I planned to have a testing install with a rabbitmq instance on 3.X,
with the plugin, upgrade it and see what happened to the existing plugin
dir. But then the current issue came up.
* What exactly did you do (or not do) that was effective (or
ineffective)?
So, on existing testing installs or on future upgrades from D12 to D13.
Rabbit will jump 🐇 from 3.10.8 to 4.0.5.
But «You can only upgrade to RabbitMQ 4.0 from RabbitMQ 3.13.»
https://www.rabbitmq.com/docs/upgrade
«stable feature flags have to be enabled before the upgrade. The upgrade
will fail if you miss this step.»
I'm not sure how to read this but there seem to be stable feature flags
after 3.10.x https://www.rabbitmq.com/docs/feature-flags#core-feature-flags
I tried in a D13 container: existing 3.10.x install; rabbitmqctl
enable_feature_flag all ; upgrade
* What was the outcome of this action?
Can't restart due to missing stream_single_active_consumer.
Which is listed as being introduced in 3.11.0.
So 4.0 expects data that was migrated by running a command on a more
recent 3.X release. But they don't exist on any Debian repo. (And do
that before upgrading to 4.0) It's impossible without getting another
release from somewhere else. And then upgrade to 4.0
So IIUC there is no clean upgrade path possible.
* What outcome did you expect instead?
I don't know how such upgrade constrains can be properly handled by
packaging.
Arch Linux users can get away with recommending wiping the install.
(that would likely also circumvent the current issue)
https://wiki.archlinux.org/title/RabbitMQ#Upgraded_RabbitMQ_to_latest_version_and_cannot_start
Maybe any install really needing to not never loose the content of the
queue would have multiple nodes? Which would be upgraded separately and
wiping wouldn't be and issue as it will be replicated after.
I'm not really a user of RabbitMQ so sorry for eventual big
misunderstandings of the nature of the issue.
Thanks for you maintenance work.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
--
tuxayo
