Hide Forgot
Description of problem: I've found that when deploying an HA overcloud with network isolation, the haproxy stats ends up listening to a VIP. I.e. the following snippet from /etc/haproxy/haproxy.cfg listen haproxy.stats bind 192.0.2.19:1993 mode http stats enable stats uri / Now do note that 192.0.2.19 is a VIP. Which means the stats from the other two haproxy instances, which may be handling e.g. the public or private API:s are not accessable. Version-Release number of selected component (if applicable): openstack-tripleo-heat-templates-0.8.6-94.el7ost Expected results: I would expect the haproxy stats to be listening on a local IP on each instance. Additional info: Do note that with the default configuration, the haproxy stats end up on the provisioning network. Not quite convinced this is the intuitive choice...
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
This is still happening with OSP9, the haproxy.stats service is listening to a VIP
From puppet-tripleo/manifests/haproxy.pp, this is where it is added: $haproxy_stats_bind_opts = { "${controller_virtual_ip}:1993" => $haproxy_listen_bind_param, This seems to be logical IP to use to count packets haproxy stats, but following up on this.
Yes, using the controller VIP is the implemented and expected IP to use for haproxy stats. The recommendation is to close this as NOTABUG and open an separate RFE to get stats from the local IPs on the instances.
Thanks Bob! Converting to an RFE and stopping targeting Newton. Please check if the updated title is right.
as far as I can see it is fixed in both osp13 and osp16, I hope it is OK for you/your customer.