Comment 4 for bug 1624791

If we preserve pyOpenSSL installed in the container, here is a dissected pcap dump of the Horizon container trying to contact Keystone without success: http://paste.openstack.org/show/581191/

Please note that the connection is closed by the client (Horizon) side just after the 3-way TCP handshake occurs. It is Horizon (Src: 10.0.3.121) who sends the first FIN/ACK (Frame 4).

Compare with a successful connection to Keystone: http://paste.openstack.org/show/581196/

When a successful connection occurs, Frame 4 is a TLS Client Hello sent by Horizon.

In short: closing the connection is clearly a decision of the client (Horizon) side. It is not a decision of HAProxy nor of Keystone.

Jesse suggested removing an ``horizon_endpoint_type: publicURL`` override which I had in my user vars. By doing this, dashboards accessing their respective servers seem to have become more reliable, but logging to Horizon is still unreliable. This because Horizon still uses the public endpoint for contacting Keystone when the user logs in, although the config now contains ``OPENSTACK_ENDPOINT_TYPE = 'internalURL'``.

The reason why the client sends the FIN/ACK more frequently when contacting a public IP address is still not very clear to me. Maybe this behaviour is related to the LXC NAT network it has to use to reach a public IP address. But then, why does it not happen when using Python's native SSL implementation in place of pyOpenSSL?