The rabbitmq state has only the current server

[post707]

[root@k8smaster k8s_statefulsets]# FIRST_POD=$(kubectl get pods --namespace test-rabbitmq -l 'app=rabbitmq' -o jsonpath='{.items[0].metadata.name }') [root@k8smaster k8s_statefulsets]# kubectl exec --namespace=test-rabbitmq $FIRST_POD rabbitmqctl cluster_status Cluster status of node 'rabbit@12.240.2.143' [{nodes,[{disc,['rabbit@12.240.2.143']}]}, {running_nodes,['rabbit@12.240.2.143']}, {cluster_name,<"rabbit@rabbitmq-0.rabbitmq.test-rabbitmq.svc.cluster.local">}, {partitions,[]}, {alarms,[{'rabbit@12.240.2.143',[]}]}]

The rabbitmq state has only the current server, and does not show the state of the entire cluster. What's the problem?thank you

[michaelklishin]

Thank you for your time.

Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. This assumes two things:

1. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team)
2. We have a certain amount of information to work with

We get at least a dozen of questions through various venues every single day, often quite light on details. At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because of that questions, investigations, root cause analysis, discussions of potential features are all considered to be mailing list material by our team. Please post this to rabbitmq-users.

Getting all the details necessary to reproduce an issue, make a conclusion or even form a hypothesis about what's happening can take a fair amount of time. Our team is multiple orders of magnitude smaller than the RabbitMQ community. Please help others help you by providing a way to reproduce the behavior you're observing, or at least sharing as much relevant information as possible on the list:

• Server, client library and plugin (if applicable) versions used
• Server logs
• A code example or terminal transcript that can be used to reproduce
• Full exception stack traces (not a single line message)
• rabbitmqctl status (and, if possible, rabbitmqctl environment output)
• Other relevant things about the environment and workload, e.g. a traffic capture

Feel free to edit out hostnames and other potentially sensitive information.

When/if we have enough details and evidence we'd be happy to file a new issue.

Thank you.

[michaelklishin]

Reasons can vary from the natural race condition described in How It Works to a low startup delay to a misconfiguration to an implementation-specific issue.

Without knowing what version of the plugin is used and whether this can be repeatedly reproduced it is impossible to provide an informed answer. Use 0.8.0, turn on debug logging for the plugin and once you have more information, start a rabbitmq-users thread.