OpenStack Day 6.5 - A Brief Detour with the Triple-O UI

We now have a two node OverStack consisting of one compute node and one controller node.

Triple-O UI Detour

Before we go to the OverCloud, lets ponder the dashboard and some GUI on the undercloud. The TripleO docs list two 'Basic Deployment' options: CLI (which is the way I went) and GUI. Apparently "Part of the Undercloud installation is also Tuskar-UI which you can use to drive deployment". Tuskar-UI is one of the two components that make up Tuskar. Tuskar is built with Triple-O in mind so this shouldn't even be surprising.

What's Tuskar? "Tuskar gives administrators the ability to control how and where OpenStack services are deployed across the datacenter.". Mmmmkay. The gist is that with Tuskar we can create resource classes and then Tuskar will use performance monitoring, health statistics, and other metrics to aid us in capacity planning.

Tuskar-UI is built on top of Horizon and provides a UI into the Tuskar data. So at this point we're pretty sure there's a GUI running on the undercloud. The TripleO docs say to create an SSH tunnel pointing port 8080 to port 80 on localhost. I have doubt. It also talks of editing /etc/openstack-dashboard/local_settings also which isn't something that even exists. I expect these docs might be a little... dated.

If we look at /etc/httpd/conf.d we see '25-tripleo-ui.conf'. This says to listen on port 3000 of our internal IP. So... First pass, lets SSH tunnel to port 3000 and see what shakes out.

$ netstat -an | grep 3000
tcp        0      0 192.168.50.1:3000       0.0.0.0:*               LISTEN

It's only listening on the management interface so we can use port 3000 on our external interface.

$ ssh -g -N -L {EXT_IP}:3000:192.168.50.1:3000 root@192.168.50.1
root@192.168.50.1's password:

Then we point our browser at http://{EXT_IP}:3000/

Progress. The username and password can be found in the stackrc file:

OS_USERNAME=admin

OS_PASSWORD=${sudo hiera admin_password}

Hiera is part of Puppet which we touched on briefly last post.

$ sudo hiera admin_password
d32545245ea237fd144218a0b6d91278af259339

If I drop this info in and hit the login button I'm presented with 'Connection Error: Connection to Keystone is not available'. *sigh* The question becomes do I need to forward the keystone port (5000) also or is it some other issue?

Taking the simple way out and just attaching a workstation to the 192.168.50.0/24 network. The top of our DHCP range is .250 so I'm taking .254 for my workstation testing. Pointing my browser at http://192.168.50.1:3000/ got the login. The login worked perfectly... and there's a lot of interesting information there including login information to my overcloud (which is apparently parked at 192.168.50.103). The right hand side also appears to be stocked with validation information. So the short answer is that it's a networking issue.

So this bit of networking and lack of information doesn't surprise me at all. When I hand rolled an instance I had to create a separate gateway machine to allow external access to Horizon. Pretty annoying and it makes me wonder if I'm doing something wrong. Accessing the GUIs just shouldn't be a difficult thing.

In my hand rolled deployment there was not a director. Since we've said the director is the gateway for the management network that means we would need to do our inbound gateway there as well since there will be NAT and it'd get weird if we didn't send it through a single mapping. I'm forced to ponder how the floating IPs are going to work at this point as well. Those should be handled by our controller which will do the bridging and security via Neutron.

One thing at a time. The obvious way would be to do a bit of port forwarding using iptables or such. Sadly this will fail. In /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js it defines keystone as http://192.168.50.1:5000/v2.0 ... this makes its way to your browser and your browser will try to access that directly. It will fail.

Rather than trying to change all of the configuration to play nice with me the answer is probably a web proxy on that network (squid or nginx). Most of OpenStack is RESTful interfaces so this should just work. (yep, famous last words... let's see).

I'm more familiar with squid so...

# yum install squid squid-sysvinit
# vi /etc/squid/squid.conf

• Add my IP t the localnet src ACL
• Comment out the 'http_access deny ~Safe_ports' line (we could have added keystone to the safe ports maybe)
• Comment out 'http_access deny CONNECT ~SSL_ports'

# /etc/init.d/squid restart

Change my browsers proxy settings to use the external IP of the director on port 3128 and tell it to use that proxy for all ports.

And Voila... my windows workstation can now access the Undercloud UI.

So what? Well the UI gives us another data point to help us confirm or reject some of our assumptions. It also provides a way to see some possible weirdness before it's an issue. Also you just may find it easier to manage Nodes and roles from this interface.