Deprecate queue-master-locator

[mkuratczyk]

• this should not be a breaking change - all validation should still pass
• CQs can now use queue-leader-locator
• queue-leader-locator takes precedence over queue-master-locator if both are used
• regardless of which name is used, effectively there are only two values: client-local (default) or balanced
• other values (min-masters, random, least-leaders) are mapped to balanced
• exclusive queues are always declared locally, as before

[michaelklishin]

@mkuratczyk I have added the new suite to Bazel.

[mkuratczyk]

We can, even now, but I wouldn't rush with actually enforcing anything. The amount of code needed to support the old name is tiny and there can be applications that have that name in the codebase and we all know that for some users, application code changes are very hard (this particular setting is probably much more common in policies, that are easier to change, but still).

[ansd]

We can, even now, but I wouldn't rush with actually enforcing anything.

No, we can't remove support for queue-master-locator right now because - as you wrote - applications use queue-master-locator. The question is how can we eventually remove support for queue-master-locator in RabbitMQ (e.g. version 5.0)? The deprecated feature subsystem enables "a way to declare deprecated features in the code, not only in our communication.".

Users might not read the documentation and might not even understand that queue-master-locator is deprecated. As explained in https://github.com/rabbitmq/rabbitmq-server/pull/7390#issue-1595515010 deprecation of queue-master-locator would go through the following lifecycle:

• permitted_by_default
• denied_by_default
• disconnected
• removed

We already use this deprecated feature subsystem for various deprecated features. It might be a good idea to also "properly" deprecate queue-master-locator using the deprecated feature subsystem.

[dumbbell]

As I said on Slack, I also favor the use of deprecated features because it increases the chance that the information reaches the user who rely on that feature. It also allows them to test RabbitMQ as if the feature was gone.

[mkuratczyk]

Corresponding docs PR: https://github.com/rabbitmq/rabbitmq-website/pull/1961

[ansd]

same for policies in the Management UI:

[ansd]

I'm unable to test upgrades from v3.13.x to this PR branch using make run-broker because the node fails during boot with this PR branch:

2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0> BOOT FAILED
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0> ===========
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0> Exception during startup:
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0> throw:{timeout,{rabbitmq_metadata,rabbit@V333JFK777}}
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>     rabbit_khepri:-register_projections/0-lc$^9/1-0-/1, line 1087
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>     rabbit_khepri:register_projections/0, line 1088
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>     rabbit_khepri:setup/1, line 255
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>     rabbit:run_prelaunch_second_phase/0, line 380
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>     rabbit:start/2, line 902
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>     application_master:start_it_old/4, line 293
2024-07-11 13:10:08.727825+02:00 [error] <0.262.0>

[ansd]

If you have tested that upgrades from v3.13 to this PR branch work with classic queues with x-queue-master-locator queue argument or queue-master-locator policy set and a subsequent upgrade where the new deprecated feature is denied, and the classic queue declaration by the client keeps working without having to re-create the classic queue, I'm happy with this PR being merged.