make vrrp network provider configurable

[Edward Hope-Morley]

Currently if I deploy Neutron with L3HA the vrrp traffic (keepalived) will always go over the network provided by the first provider defined in tenant_network_types (which in most cases will be gre). If a deployment is not using the same physical interface/bond for the tenant and external traffic then it does not make sense to have things setup like this since if there is a problem with the external network access to a host, keepalived will not notice unless the same problem impacts the tenant network. Therefore we should allow users to configure the l3_ha_network_type and l3_ha_network_physical_name config options to allow a separate provider to be used if one is available.

[Edward Hope-Morley (hopem)]

One other thought is that with the current configuration (vrrp clustering using overlay/tunnel network) if the tenant east-west traffic saturates the network such that vrrp health checks start to time out, this could cause unnecessary re-elections/transitions which would have the knock-on effect of adding extra load to the environment (as neutron would need to keep up with this and itself generate more load in doing so).

[David Ames (thedac)]

Ed,

I agree this is necessary. We'll have discussions on priority setting.

TRIAGE:

Ed's description is a valid use case for the need to be able to specify where the VRRP traffic is sent.