[Openstack-operators] [OCTAVIA][KOLLA] - Amphora to control plan communication question.

Flint WALRUS gael.therond at gmail.com
Tue Jul 31 17:05:11 UTC 2018

Hi Michael, thanks a lot for that explanation, it’s actually how I
envisioned the flow.

I’ll have to produce a diagram for my peers understanding, I maybe can
share it with you.

There is still one point that seems to be a little bit odd to me.

How the amphora agent know where to find out the healthManagers and worker
services? Is that because the worker is sending the agent some catalog
informations or because we set that at diskimage-create time?

If so, I think the Centos based amphora is missing the agent.conf because
currently my vms doesn’t have any.

Once again thanks for your help!
Le mar. 31 juil. 2018 à 18:15, Michael Johnson <johnsomor at gmail.com> a
écrit :

> Hi Flint,
> We don't have a logical network diagram at this time (it's still on
> the to-do list), but I can talk you through it.
> The Octavia worker, health manager, and housekeeping need to be able
> to reach the amphora (service VM at this point) over the lb-mgmt-net
> on TCP 9443. It knows the amphora IP addresses on the lb-mgmt-net via
> the database and the information we save from the compute driver (I.e.
> what IP was assigned to the instance).
> The Octavia API process does not need to be connected to the
> lb-mgmt-net at this time. It only connects the the messaging bus and
> the Octavia database. Provider drivers may have other connectivity
> requirements for the Octavia API.
> The amphorae also send UDP packets back to the health manager on port
> 5555. This is the heartbeat packet from the amphora. It contains the
> health and statistics from that amphora. It know it's list of health
> manager endpoints from the configuration file
> "controller_ip_port_list"
> (
> https://docs.openstack.org/octavia/latest/configuration/configref.html#health_manager.controller_ip_port_list
> ).
> Each amphora will rotate through that list of endpoints to reduce the
> chance of a network split impacting the heartbeat messages.
> This is the only traffic that passed over this network. All of it is
> IP based and can be routed (it does not require L2 connectivity).
> Michael
> On Tue, Jul 31, 2018 at 2:00 AM Flint WALRUS <gael.therond at gmail.com>
> wrote:
> >
> > Hi Folks,
> >
> > I'm currently deploying the Octavia component into our testing
> environment which is based on KOLLA.
> >
> > So far I'm quite enjoying it as it is pretty much straight forward
> (Except for some documentation pitfalls), but I'm now facing a weird and
> hard to debug situation.
> >
> > I actually have a hard time to understand how Amphora are communicating
> back and forth with the Control Plan components.
> >
> > From my understanding, as soon as I create a new LB, the Control Plan is
> spawning an instance using the configured Octavia Flavor and Image type,
> attach it to the LB-MGMT-NET and to the user provided subnet.
> >
> > What I think I'm misunderstanding is the discussion that follows between
> the amphora and the different components such as the
> HealthManager/HouseKeeper, the API and the Worker.
> >
> > How is the amphora agent able to found my control plan? Is the
> HealthManager or the Octavia Worker initiating the communication to the
> Amphora on port 9443 and so give the agent the API/Control plan internalURL?
> >
> > If anyone have a diagram of the workflow I would be more than happy ^^
> >
> > Thanks a lot in advance to anyone willing to help :D
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180731/4eba2c8c/attachment.html>

More information about the OpenStack-operators mailing list