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. Thanks, SamYaple Sam Yaple On Mon, Mar 20, 2017 at 2:43 PM, Nikita Gerasimov < nikita.gerasi...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
