During deploy before the {leader,client}_node_is_ready returns true, regardless of the juju config value write the config file with cluster-partition-handling = ignore, then after the cluster is complete ({leader,client}_node_is_ready returns true) re-write the config with the value set in juju config.
This will avoid deploy time collisions of the rabbitmq cluster management and the charm cluster build process.
Note: The problem on a very busy cloud still exists. If the rabbitmq cluster management happens to remove a node and a juju hook subsequently we will get hook execution errors. A simple juju resolved will fix the issue.
Note:
We may need to validate {leader,client}_node_is_ready is sufficient.
The approach we need to take is the following:
During deploy before the {leader, client} _node_is_ ready returns true, regardless of the juju config value write the config file with cluster- partition- handling = ignore, then after the cluster is complete ({leader, client} _node_is_ ready returns true) re-write the config with the value set in juju config.
This will avoid deploy time collisions of the rabbitmq cluster management and the charm cluster build process.
Note: The problem on a very busy cloud still exists. If the rabbitmq cluster management happens to remove a node and a juju hook subsequently we will get hook execution errors. A simple juju resolved will fix the issue.
Note: client} _node_is_ ready is sufficient.
We may need to validate {leader,