Comment 10 for bug 1782438

Unfortunately https://review.openstack.org/599400 won't get us what we want in its current form.

If we want the TripleO UI to be accessible on an undercloud interface other than the ctlplane (which defaults to 192.168.24.x), then the undercloud Heat stack needs to be aware of the other interface(s). Currently the undercloud uplink (which is NAT'd via libvirt in virtual environments and is a regular interface in non-virtual environments) is not referenced anywhere in the undercloud Heat stack. It's just an interface with a default route on the undercloud host itself.

The undercloud_public_host value is supposed to refer to the public VIP on the undercloud, which is on the ctlplane and defaults to 192.168.24.2. This VIP is used for overcloud->undercloud API calls. If you override undercloud_undercloud_public_host to the IP of the virthost then the overcloud hosts can't reach that IP, which I suspect is why the deployment hangs.

We need to separate the TripleO UI endpoint from the undercloud public VIP. We could modify undercloud.conf to contain a reference for the IP that the UI should listen on separately from the IP that the public VIP listens on, or modify the undercloud so that there is a Neutron network that represents the uplink network. I think the easiest to implement would be an IP in undercloud.conf (undercloud_uplink_host or undercloud_external_host or even undercloud_ui_host) and use that IP to configure the UI endpoint, and perhaps default to the undercloud_public_vip if this value isn't present.