rabbitmq/rabbitmq-website

The "Quorum Queues" documentation contains contradictory statements

cat-mucius opened this issue · 4 comments

Describe the bug

The "Quorum Queues" page states:

The quorum queue will be launched to run on a random subset of RabbitMQ nodes present in the cluster at declaration time.
...
When a new quorum queue is declared, the set of nodes that will host its replicas is randomly picked, but will always include the node the client that declares the queue is connected to.

On another hand, it also states:

Replicas of a quorum queue are explicitly managed by the operator. When a new node is added to the cluster, it will host no quorum queue replicas unless the operator explicitly adds it to a member (replica) list of a quorum queue or a set of quorum queues.

To me this seems confusing and contradictory.

Does this mean that operator has no control on the initial nodes to be running a quorum queue, but once the queue is formed on them, he can select the preferred nodes by adding and removing the queue's replicas manually? Seems pretty strange.

Is there any way to declare preferred nodes during creation of a quorum queue?

Reproduction steps

Read the doc. :-)

Expected behavior

I'd expect the doc to be more clear. :-)

Additional context

No response

Cluster Operator only has control over the leader replica placement placement used. It has no say in quorum queue or stream replica placement otherwise, and RabbitMQ nodes are not aware of any Kubernetes operators or features (besides the peer discovery mechanism).

There is no way to declare preferred nodes and you should not try to pick them.

I was describing the K8S Operator. If this is human operators that we are talking, then the initial placement is controlled by the leader placement strategy but replicas can be added or removed explicitly using CLI tools. It only makes sense to do so when new nodes are added or nodes must be decommissioned.

Hi @michaelklishin,

The "Quorum Queues" page doesn't mention Kubernetes at all...

By "leader placement strategy" do you mean the queue-leader-locator parameter?

So if I understood correctly - let's say I have a cluster of 5 nodes, I've added a quorum queue and its replicas were placed on Node1, Node4, Node5. If I want them on first three nodes instead, then the only method I can use is to:

  • discover the nodes selected by cluster postfactum, after creation of the queue;
  • run:
# rabbitmq-queues add_member myqueue Node2
# rabbitmq-queues add_member myqueue Node3
# rabbitmq-queues delete_member myqueue Node4
# rabbitmq-queues delete_member myqueue Node5

Is this accurate?

Correct on both counts. I will clarify the language in the guide.