[openstack-dev] [kolla] rabbitmq cluster_partition_handling config in kolla-ansible

Sam Yaple samuel at yaple.net
Mon Mar 20 18:15:13 UTC 2017

Hello Nikita,

There is no technical reason this cannot be made variable. I don't think
anyone could come up with a valid reason to block such a patch.

However, I would ask what you plan to gain from _not_ having it 'autoheal'?
The other options for partition handling are basically "let it partition
and do nothing" and "quarantine the partitioned node". Each of those
require an operator to take action. I have not personally known a single
OpenStack operator to ever go and recover a message from a partitioned
rabbitmq node and reinject it into the cluster. In fact, I do not know if
that would even be an advisable action given the retries that exist within
OpenStack. Not to mention the times when the resource was, say, a new port
in Neutron and you reinject the message after the VM consuming that port
was deleted.

With the reasons above, it is hard to justify anything but 'autoheal' for
OpenStack specifically. I certainly don't see any advantages.

Now that the ask has been made though, a variable would be 2 lines of code
in total, so I say go for it.


Sam Yaple

On Mon, Mar 20, 2017 at 2:43 PM, Nikita Gerasimov <
nikita.gerasimov at oracle.com> wrote:

> Hi,
> Since [1] kolla-ansible have rabbitmq cluster_partition_handling option
> hard-coded to 'autoheal'. According to [2] it's not a best mode for 3+ node
> clusters with reliable network.
> Is it reasonable to make this option changeable by user or even place some
> logic to pickup mode based on cluster structure?
> Or we have a reason to keep it hard-coded?
> [1] https://github.com/openstack/kolla-ansible/commit/0c6594c258
> 64d0c90cd0009726cee84967fe65dc
> [2] https://www.rabbitmq.com/partitions.html
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170320/bf388965/attachment.html>

More information about the OpenStack-dev mailing list