tripleo ui endpoints misconfigured in containerized undercloud

bash quickstart.sh \
    -e undercloud_undercloud_public_host=<virthost ip> \
    --clean \
    --tags all \
    --teardown all \
    --release master \
    --no-clone \
    $VIRTHOST

Quickstart is not productized, it is dev/CI only tool. The alert mark comes for CI/promotion cases, which can live w/o UI. Hence, I'm removing 'alert'.

Might be something in dockerfile that is not being configured http://git.openstack.org/cgit/openstack/kolla/tree/docker/tripleo-ui/Dockerfile.j2

Still trying to figure out where the config file gets written (tripleo_ui_config.js)

http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/docker/services/tripleo-ui.yaml

Puppet writes those values. In puppet-tripleo:

http://git.openstack.org/cgit/openstack/puppet-tripleo/tree/manifests/ui.pp#n211

And those values in turn come from:

http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/puppet/services/tripleo-ui.yaml#n80

But I'm not sure how it gets to that. From the network data file, I think. Before docker, it used to come from instack-undercloud.

Actually, now I think that the current behavior is correct. I should be required to set up an ssh tunnel from my laptop to the undercloud. This is what I do on RDO Cloud. As such, I don't think this is a bug; we can have a separate discussion about if we want to change it or not. If there is no disagreement, I'll close this in a few days.

I disagree - the undercloud UI should be accessible outside of the container without additional re-configuration or an outside tool such as sshuttle. Can you elaborate how you're doing your setup?

Using

     -e undercloud_undercloud_public_host=$VIRTHOST_IP (NOTE: IP, not hostname)

seems to correctly change the values in tripleo_ui_config.js. However, it leaves the value in httpd alone.

Fix proposed to branch: master
Review: https://review.openstack.org/599400

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.

I have to note that the situation with those undercloud_public*
host/vip vs admin* parameters, and network configs, and (not working?) composable networking mappings for public/internal networks - is highly confusing. This really needs to be improved as Dan proposes. Especially given the Edge case in mind, where we might need more than just ctlplane and routed "fake" public/internal networks, but *real* public and internal networking...

Note that the UI has always only listened on the ctlplane interface, unless SSL and haproxy are enabled, then it is accessible via the public vip.

So I'm not entirely sure this is a bug?

Change abandoned by wes hayutin (<email address hidden>) on branch: master
Review: https://review.opendev.org/599400
Reason: https://specs.openstack.org/openstack/tripleo-specs/specs/policy/patch-abandonment.html