Octavia health-manager and worker should work better with any given interface_driver

[Nir Magnezi]

The octavia-health-manager service is dependant on the deployment tool to provide it with a port (usually an OVS port) and a NIC with a correlated IP address that can guarantee it can communicate with amphoras using the lb-mgmt-subnet.

Examples of that dependency:
Devstack:
https://github.com/openstack/octavia/blob/master/devstack/plugin.sh#L309

TripleO:
neutron side (adds an option to skip ports cleanup) https://review.openstack.org/#/c/460524/
TripleO docs: https://review.openstack.org/#/c/447496/31/doc/source/install/advanced_deployment/deploy_octavia.rst@186

Octavia Ansible:
which basically work around the issue by listening to 0.0.0.0: https://github.com/openstack/openstack-ansible-os_octavia/blob/master/templates/octavia.conf.j2#L38-L42

In addition, the octavia-worker service also needs to communicate with amphorae, it basically takes advantage of the route created by the addition of the o-hm0.

This creates few problems:
1. both the health-manager and worker services must reside on the same node.
2. Octavia can only operate with interface drivers that are currently supported by the deployment tools.

Suggested solution:
neutron (and neutron-lbaas) get the interface_driver as a configuration option. The interaction with the interface driver is managed[1] in the codebase and by that:
1. There is no dependency with the deployment tool.
2. Third party interface drivers can be used by Octavia. This is mostly important for deployments who currently use neutron (or neutron-lbaas) with a third party interface driver (Nuage for example) and want to use Octavia. Such deployments will have the ability to adapt Octavia without any custom in-house deployment.

IMHO, both octavia health manager and worker to take advantage of:
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/interface.py

[German Eichberger (german-eichberger)]

For sensible please note we also deploy an I-tables firewall on the interface which connect to mgmt.

[Michael Johnson (johnsom)]

A few comments:

1. There is not requirement for health manager and the controller work process to reside on the same node.
2. By doing this, wouldn't it add an artificial requirement to have neutron services available on the instance running the octavia processes?

Currently it is up to the operator installing Octavia to decide how is best to get these processes access to the neutron lb-mgmt-net. This allows flexibility to use whatever technology they want to provide that access. It could be a VLAN, VXLAN, GRE, physical interface, etc.

Maybe I am not fully understanding the proposal.

[Michael Johnson (johnsom)]

Is this a duplicate of: https://bugs.launchpad.net/octavia/+bug/1549297 ?

[Gregory Thiemonge (gthiemonge)]

Abandoned after re-enabling the Octavia launchpad.