The generated haproxy.cfg is using addresses on the provisioning network:
server mac5254009d59ff.localdomain 172.16.0.8:5000 check inter 1s
server mac525400960dc7.localdomain 172.16.0.10:5000 check inter 1s
server mac525400c1a0af.localdomain 172.16.0.15:5000 check inter 1s
But the services are actually configured to bind to a different address:
# grep bind_host /etc/keystone/keystone.conf
These two pieces of information should be coming from the same source. I think the haproxy.cfg is correct (e.g., the services should listen on the provisioning network).
The service bind adde comes from whatever ip is determined from private_|iface|network|ip, the haproxy server list comes from lb_backend_server_addrs, so wherever these values are getting gee rated to pass into quick stack needs to match. Moving to staypuft, as this works if the correct values are passed in
In the puppet yaml for these hosts:
Whereas in /var/named/dynamic/db.localdomain:
mac5254002ba3e5 A 172.16.0.12
mac525400820497 A 172.16.0.11
mac525400960dc7 A 172.16.0.10
mac5254009d59ff A 172.16.0.8
mac525400c1a0af A 172.16.0.15
And private_ip has the wrong address in the YAML:
mac525400960dc7.localdomain.yaml: private_ip: "10.16.71.200"
mac5254009d59ff.localdomain.yaml: private_ip: "10.16.71.183"
mac525400c1a0af.localdomain.yaml: private_ip: "10.16.71.178"
It's looking like this came about from an older staypuft installer version.
ignore_puppet_facts_for_provisioning should be set to true with the latest installer, but it was set to false for this failed run. If it's false, then facter will sometimes update the ip for the controllers to use the wrong interface (in this case it's using the external one rather than the provisioning one).
based on comment 4, this is a duplicate of previous bugs that are already fixed. Please reopen if this persists.