octavia-health-manager requires a host-wise plugged interface to the lb-mgmt-net

[Miguel Angel Ajo]

Problem

The lb-mgmt-net subnet could collide with any of the host networks, and the use of the dhcp-agent [2] could overwrite host settings at port plug time, I guess that deployments should at least get the fixed IP provided by neutron and stick to that.

Solutions

I believe it should be the health-manager itself who should be plugging the interface, and not the deployment tools. [1]

Ideally, we could plug the interface inside a netns, and have a sub-agent of the health-manager inside the namespace (rootwrap-daemon-like: [3]) the python multiprocessing managers class, allow you to spawn a separate process (in a namespace), and make any call to it transparently via unix socket.

[1] https://github.com/openstack/octavia/blob/dd542b10805f3373dd9c3a5f00456e0a1a64e653/devstack/plugin.sh#L123-L135
[2] https://github.com/openstack/octavia/blob/dd542b10805f3373dd9c3a5f00456e0a1a64e653/devstack/plugin.sh#L131
[3] https://github.com/openstack/oslo.rootwrap/blob/master/oslo_rootwrap/daemon.py

[Assaf Muller (amuller)]

The DHCP and L3 agents also need ports in Neutron networks. They do it by having the agent create a namespace and a port in the namespace. We don't do it by requiring the OpenStack deployment tool set up a port in the root namespace. Hopefully the disadvantages of this approach are clear.

[Miguel Angel Ajo (mangelajo)]

Yes, but the l3-agent and dhcp-agent spawn the services themselves inside the namespace, I guess
the issue with the health manager, is that it's the agent itself who contacts the hosts, and still needs
connection to DB/(AMQP?).

For a namespace to be possible, I guess the agent (or some part of it) would need to be split into
a separate daemon, so that one is able to talk to the amphoraes, while the main agent is able to talk
to DB.

[Assaf Muller (amuller)]

I'm not following. The L3 agent process lives in the root namespace and talks to the AMQP bus. It then spawns namespaces and puts ports in those namespaces so its routers could talk to VMs in their Neutron networks. We cannot apply this design to the health agent?

[Miguel Angel Ajo (mangelajo)]

No, you need like a sub-agent (like ns-metadata-proxy but just one instance per cloud) which is the one that will have connectivity to the amphoras (from inside the namespace).

root ns (host connectivity, not to amphoras)
~~~~~~
octavia-health-manager

/|\
 |
 |
\|/

lb-mgmt-net-namespace (only connectivity to amphoras)
~~~~~~~~~~~~~~~~~~~~~
sub-agent-that-really-checks/talks-to-amphoras

[Miguel Angel Ajo (mangelajo)]

Ok, I'm not already sure octavia-health-manager talks to the amphoras to
have do health checks?

[cheng (tangch318)]

Currenly, many Paas project (eg. trove) need to communication with VM in tenant network. Whether there has an general solution to make it possible.

[Gregory Thiemonge (gthiemonge)]

Abandoned after re-enabling the Octavia launchpad.