Comment 29 for bug 1583694

I took the time to look into this issue and I want to make sure I fully understand the context here.

To recap: report for bug 1445255 was reported to complain about lack of DVR support for VRRP use cases as described in blog post [1]. This was fixed and backported. However, this bug report was also filed in relation to a use case for LBaaS/Octavia.

It is my understanding that the fix for bug 1445255 is only effective if the VRRP failover is triggered by manually marking DOWN the admin status of the port to which the faulty Octavia instance is associated with, and thus it is totally ineffective otherwise. Involving the Neutron API for failover is clearly not acceptable. However, it is my understanding that using FIP/VRRP in conjunction with centralized routing, no manual failover is necessary; in other words, a keepalived instance can go down and the cluster will adjust itself seamlessly irrespective of the Neutron port status.

I hope someone can confirm that's the current state of affairs.

Now, I may argue that fix for bug 1445255 is in itself inadequate, and we should not treat this report as RFE per se. Having said that, if the user's intention is to use a Floating IP (FIP) with multiple ports at any given time by leveraging allowed address pairs as a binding mechanism between the FIP and ports via an unbound (utility) port that carries the keepalived VIP, then the distributed nature of the routing function supporting the FIP has unveiled a clear limitation of the very model employed to achieve this use case. Perhaps this RFE calls for figuring out new ways to achieve this use case in a way that the relationship between the FIP and ports involved is more clearly defined and would make the centralization of the FIP function for DVR less of an issue, especially if case the FIP ends up being reused for other use cases across its life cycle.

Thoughts?

[1] http://superuser.openstack.org/articles/implementing-high-availability-instances-with-neutron-using-vrrp