Comment 6 for bug 1764925

looks like this is an issue with autoclustering.
nodem7 starts when nodem14 is not ready to accept connections.

as a workaround I made in the rabbitmq container on nodem7:

root@nodem7:/# rabbitmqctl -n contrail@nodem7 stop_app
Stopping rabbit application on node contrail@nodem7
root@nodem7:/# rabbitmqctl -n contrail@nodem7 join_cluster contrail@nodem14
Clustering node contrail@nodem7 with contrail@nodem14
root@nodem7:/# rabbitmqctl -n contrail@nodem7 start_app
Starting node contrail@nodem7

and then cluster looks good:

root@nodem7:/# rabbitmqctl -n contrail@nodem14 cluster_status
Cluster status of node contrail@nodem14
[{nodes,[{disc,[contrail@nodem14,contrail@nodem6,contrail@nodem7]}]},
 {running_nodes,[contrail@nodem7,contrail@nodem6,contrail@nodem14]},
 {cluster_name,<<"<email address hidden>">>},
 {partitions,[]},
 {alarms,[{contrail@nodem7,[]},{contrail@nodem6,[]},{contrail@nodem14,[]}]}]
root@nodem7:/# rabbitmqctl -n contrail@nodem7 cluster_status
Cluster status of node contrail@nodem7
[{nodes,[{disc,[contrail@nodem14,contrail@nodem6,contrail@nodem7]}]},
 {running_nodes,[contrail@nodem14,contrail@nodem6,contrail@nodem7]},
 {cluster_name,<<"<email address hidden>">>},
 {partitions,[]},
 {alarms,[{contrail@nodem14,[]},{contrail@nodem6,[]},{contrail@nodem7,[]}]}]

another workaround is to restart container that is not in the cluster