[Openstack-operators] [openstack] [Octavia] unable to contact instance

Joris S’heeren Joris.Sheeren at combellgroup.com
Wed Jun 29 23:15:11 UTC 2016


Hi all,

We are in the process of configuring the octavia lbaasv2 service.
On our mitaka environment we are using neutron dvr with openvswitch.  We have multiple controllers (3 to be exact).
We're following https://github.com/openstack/octavia/blob/stable/mitaka/devstack/plugin.sh as a guide.

After creating a load balancer, the amphora instance is booted.  It receives ips in the lb-net and the private network.

The octavia-worker log show:
DEBUG octavia.amphorae.drivers.haproxy.rest_api_driver [-] request url plug/vip/192.168.1.126 request /octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py:218
DEBUG octavia.amphorae.drivers.haproxy.rest_api_driver [-] request url https://192.168.246.11:9443/0.5/plug/vip/192.168.1.126 request /octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py:221
WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to instance. Retrying.
WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to instance. Retrying.
etc...

I can ping the amphora instance on the lb-net; not on the private net as it has not received the request to activate the second interface.  I can ssh into the amphora instance from the lb-net namespace.
The amphora agent is running inside the amphora instance and listening on port 9443, the correct sec group is attached to the amphora instance so that should not be an issue.

Also we can see in dmesg :
[216682.378571] BLOCKED OUTPUT : IN= OUT=eth0 SRC=1.2.3.4 DST=192.168.246.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=19651 DF PROTO=TCP SPT=34464 DPT=9443 WINDOW=29200 RES=0x00 SYN URGP=0

We can see the worker trying to contact the amphora instance
octavia-w 31502 octavia   13u  IPv4 27647551      0t0  TCP 1.2.3.4:35304->192.168.246.11:9443 (SYN_SENT)

Do the octavia processes try to contact the amphora instance directly at it's lb-net ip? Not through a namespace?
For this to work, do we need to configure the health manager ports as described here: https://github.com/openstack/octavia/blob/stable/mitaka/devstack/plugin.sh#L123
Or setup some iptables rules or routes?

Kind regards
Joris S'heeren

--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160629/6699b9c9/attachment.html>


More information about the OpenStack-operators mailing list