stable/queens branch: dashboard not responding after successful installation message

asked 2018-05-09 13:25:41 -0600

J A gravatar image

After bare metal installation using the stable/queens branch of devstack, I tried to connect to the local network ip/dashboard provided at the end of installation. Tried from a different computer inside my own network to no avail. I pinged the local ip and it does respond.

I can curl out to the internet and get my public ip so I know the computer can call home.

iptables show very permissive rules allowing tcp and ssh traffic

My only guess is that it wasn't correctly installed and didn't run even when it finished with no errors.
To be clear, the first installation attempt did exit with error code, I updated pip and rerun the installation script ./

I checked for memory consumption and it would seem as if it is actually running.
top command does list a number of processes that are being executed by the stack user:

nova-conductor (2 processes)
cinder-volume (2 processes)

and beam.smp by rabbitmquser

I see no dashboard process.

I tried curling locally to ip/dashboard to no avail either.

So, I reinstalled linux and pip and upgraded pip to ver.10 I read documentation saying openstack dropped python 2.6 support but I'm using 2.7 so we're ok in that aspect. I reinstalled openstack using the same stable/queens branch with a newly created stack user with admin rights and no passwd needed to sudo just the same as before, and now I'm getting a slightly different result.

curling ip/dashboard simply goes iddle and then returns with no response, trying to connect with a browser does the same but gives a "This site can’t be reached, took too long to respond ERR_CONNECTION_TIMED_OUT" error message.

On the other hand, if I curl the bare ip address from within the same system I get a 302 response

<title>302 Found</title>
<p>The document has moved <a href="">here</a>.</p>

But if I try to access the bare ip from another equipment using a browser, I get the same "This site can’t be reached, took too long to respond ERR_CONNECTION_TIMED_OUT" error message.

I'm now suspecting curl is not the adequate tool to diagnose because unless I activate javascript and pass some headers, and there might indeed be a problem at iptables, only I'm not an expert at all on that aspect of networking, I'm on the blind here, can anyone help?

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
neutron-openvswi-INPUT  all  --  anywhere             anywhere
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere ...
edit retag flag offensive close merge delete