<div dir="ltr">On 14 March 2015 at 00:16, John Williams <span dir="ltr"><<a href="mailto:john.1209@yahoo.com" target="_blank">john.1209@yahoo.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm on the following URL of the build docs<br>
<br>
<a href="http://docs.openstack.org/juno/install-guide/install/apt/content/keystone-users.html" target="_blank">http://docs.openstack.org/juno/install-guide/install/apt/content/keystone-users.html</a><br>
<br>
<br>
I'm trying to put keystone together.  The build is failing on the following:<br>
<br>
root@os1:/etc# keystone tenant-create --name admin --description "Admin Tenant"<br>
WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).<br>
Unable to establish connection to <a href="http://os1:35357/v2.0/tenants" target="_blank">http://os1:35357/v2.0/tenants</a><br>
root@os1:/etc#<br>
<br>
<br>
<br>
Any idea what the problem may be?<br>
<br>
Thanks in advance.<br>
</blockquote><div><br></div><div>Hi John,<br><br></div><div>The most obvious things I can think of:<br><br><div> - Service not running<br><br></div>Easy enough to check:<br><br># netstat -tunlp | grep 35357<br>tcp        0      0 <a href="http://0.0.0.0:35357">0.0.0.0:35357</a>           0.0.0.0:*               LISTEN      19821/python<br><br></div><div> - 'os1' does not resolve to the server IP where keystone is expected to be running<br><br></div><div>You appear to be running the keystone command from the 'os1' instance.  I assume this is where the service is hosted and you should be able to confirm an entry in /etc/hosts (or DNS and search domain combo, should you be taking that particular approach) e.g.<br><br></div><div># grep controller /etc/hosts<br>172.16.32.100     controller<br><br></div><div># host controller<br>controller has address 172.16.32.100<br></div><div><br></div><div> - Firewall blocking requests to port 35357<br><br></div><div>Should you be making use of iptables (or similar), it is possible that requests to the IP address that 'os1' resolves to are being blocked.  Example of a firewall rule permitting keystone auth and admin API access on my local deployment and a curl request confirming it is running:<br><br># iptables -nvL --line | grep 35357<br>31     304 18240 ACCEPT     tcp  --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>            multiport ports 5000,35357  state NEW<br><br></div><div> - keystone.conf changes that have not been applied (or a misconfiguration)<br><br></div><div>If you have applied changes to keystone.conf and not restarted the service you are likely to get seemingly odd behaviour.<br><br></div><div>Failing all of that I would recommend increasing log verbosity for the keystone service ('verbose=true' and 'debug=true, under the [DEFAULT] section in keystone.conf) restarting the service, and hopefully get more useful output in the keystone log.<br><br></div><div>Regards,<br><br>--<br></div><div>Adnan<br></div></div></div></div>