tripleo ui endpoints misconfigured in containerized undercloud

Bug #1782438 reported by Honza Pokorny on 2018-07-18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Honza Pokorny

Bug Description

quickstart produces wrong endpoint values in


on the undercloud; they point to which is only accessible from the undercloud on virtualized setups. Instead, those values should point to the virthost ip address.

This was working correctly prior to the introduction of the containerized undercloud so I suspect it's a leftover from that.

I tried setting "-e undercloud_undercloud_public_host=<virthost ip>". This correctly sets the value in tripleo_ui_config.js but it freezes the undercloud installation.

I'm using the defaults, -R master.

Honza Pokorny (hpokorny) on 2018-07-18
description: updated
Changed in tripleo:
milestone: none → rocky-3
importance: Critical → High
status: New → Triaged
Honza Pokorny (hpokorny) wrote :

bash \
    -e undercloud_undercloud_public_host=<virthost ip> \
    --clean \
    --tags all \
    --teardown all \
    --release master \
    --no-clone \

Bogdan Dobrelya (bogdando) wrote :

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'.

tags: removed: alert
Changed in tripleo:
milestone: rocky-3 → rocky-rc1
Jason E. Rist (jason-rist) wrote :

Might be something in dockerfile that is not being configured

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

Honza Pokorny (hpokorny) wrote :

Puppet writes those values. In puppet-tripleo:

And those values in turn come from:

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.

Changed in tripleo:
milestone: rocky-rc1 → stein-1
Honza Pokorny (hpokorny) wrote :

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.

Jason E. Rist (jason-rist) wrote :

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?

Honza Pokorny (hpokorny) wrote :


     -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

Changed in tripleo:
assignee: nobody → Honza Pokorny (hpokorny)
status: Triaged → In Progress
tags: removed: quickstart
Dan Sneddon (dsneddon) wrote :

Unfortunately 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 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.

Bogdan Dobrelya (bogdando) wrote :

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...

tags: added: networking tech-debt
tags: added: ux
tags: added: rocky-backport-potential
Steven Hardy (shardy) wrote :

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?

Changed in tripleo:
milestone: stein-1 → stein-2
Changed in tripleo:
milestone: stein-2 → stein-3
Changed in tripleo:
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers