Replies: 2 comments
-
@motmot80 we have seen a good dozen of variations of this, and tried multiple things over the years. I only have two ideas left in mind:
I don't see how definition import can interfere with queue declaration but a booting cluster itself https://github.com/rabbitmq/ra/pulls?q=is%3Apr+is%3Aclosed is good example of how having N replicas can be see as "not good enough" early in the cluster formation process: a catching up replica is technically online but it is not functional replica. |
Beta Was this translation helpful? Give feedback.
-
Another idea suggested on the core team is: define a custom |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
Creating a queue (external client) during the cluster formation is cancelling the queue creation process from a cluster definition.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Actual behavior
Workaround
Actively suppress incoming connections as long as the cluster is not fully started and queue defintions are not applied successfully.
Analysis
If the queue creation process is intererupted by someone creating an "unexpected" queue the queue definition execution seems to be canceled.
The definitions are executed after the cluster has formed. Which it totally fine and expected.
But as soon as ONE of the RMQs nodes confirms it is ready the k8s network service lets clients connect which therefore could create local queues during cluster formation which therefore interupts the queue creation process.
Version and environment information
Additional context
In BCDR contexts it should be possible to recreate a cluster without any extra steps.
Maybe RMQ clusters should not be connectable before the are fully configured to reduce risks of inconsistent states.
Beta Was this translation helpful? Give feedback.
All reactions