Comment 15 for bug 1583694

The option at this point is pretty much open to option1 or option2.
As Kevin mentioned, if the users of the allowed_address_pair port is not able to update the neutron and inform what is the ACTIVE VM, then we should find a way to identify the ACTIVE VM port by either intercepting the GARP message sent by the Keepalived and then query the port based on the mac in the GARP and find out the host binding from that.

Then based on the hostbinding, we can trigger the GARP to be sent from the fip namespace for the migrating host.
But at this point it seems that it might not be as fast as what is seen today from a cvr by just toggeling the allowed_address_pair MAC.

As kevin mentioned, option 2, might be a temporary solution, for hybrid cases that involves the unbound port.

Here are the list of items that we need to figure out.
1. Flag the ip to be monitored for GARP on all the nodes.
2. When GARP kicks in, then either from the host, or from the router_namespace were the ARP entry changes for that ip, we should be able to send a message back to the neutron or the fip-namespace to trigger the GARP for the fipnamespace for that particular IP.
3. This again involves, creating the floatingip on all the nodes were the VM is hosted and just trigger the GARP on floating for the node where the VM is active.

Kevin I need some advice from you on the GARP intercept - were and how to proceed if this is what is the optimal solution.