Hi Flint, Happy to help.
Right now the list of controller endpoints is pushed at boot time and loaded into the amphora via config drive/nova. In the future we plan to be able to update this list via the amphora API, but it has not been developed yet. I am pretty sure centos is getting the config file as our gate job that runs with centos 7 amphora has been passing. It should be in the same /etc/octavia/amphora-agent.conf location as the ubuntu based amphora. Michael On Tue, Jul 31, 2018 at 10:05 AM Flint WALRUS <gael.ther...@gmail.com> wrote: > > 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 <johnso...@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.ther...@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@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
