Comment 9 for bug 1701061

On Tue, 04 Jul 2017 09:21:25 -0000
Frode Nordahl <email address hidden> wrote:

> DEBUG:runner:Cluster status of node
> 'rabbit@juju-4d268d-auto-osci-sv06-16' ...
> DEBUG:runner:[{nodes,[{disc,['rabbit@juju-4d268d-auto-osci-sv06-15',
> DEBUG:runner:
> 'rabbit@juju-4d268d-auto-osci-sv06-16']}]}, DEBUG:runner:
> {running_nodes,['rabbit@juju-4d268d-auto-osci-sv06-15',
> DEBUG:runner:
> 'rabbit@juju-4d268d-auto-osci-sv06-16']}, DEBUG:runner:
> {cluster_name,<<"rabbit@juju-4d268d-auto-osci-sv06-17">>},
> DEBUG:runner: {partitions,[]}] DEBUG:runner:['Cluster registration
> check failed on rabbitmq-server/6:
> rabbit@juju-4d268d-auto-osci-sv06-17 should not be registered with
> RabbitMQ after unit removal.\n'] DEBUG:runner:Exit Code: 1
>
> As you can see here the test itself is clearly in error mistaking
> value of cluster_name for a node. Making the test sleep will not
> change that, so it's passing is random with regards to which node was
> removed.
>
> So should do two things:
> 1) Update the functional test to not mistake cluster_name as a node
> in the cluster 2) Evaluate thoroughly whether we should update
> cluster_name on leader change
>
> I believe 2) is not really necessary and I avoided updating the
> cluster name in the fixes for bug 1679449 since I did not have full
> view of what side effects that could have at the time.
>
> As for bug 1691510 and the related fixes, it is not clear to me how
> that code is using cluster_name for anything?

I was reading the code and I couldn't find anything using the
cluster_name besides testing code. So I think we could just set the
cluster to any string (e.g. rabbitmqctl set_cluster_name juju) and stop
caring about it, there is no reason to keep synced with the current
juju leader.