[openstack-dev] [keystone] keystoneauth version auto discovery for internal endpoints in queens

Vlad Gusev gusev at selectel.ru
Fri May 11 20:37:06 UTC 2018


We faced a bug in keystoneauth, which haven't existed before Queens.

In our OpenStack deployments we use urls like http://controller:5000/v3 for
internal and admin endpoints and urls like
https://api.example.org/identity/v3 for public endpoints. We set option
public_endpoint in [default] section of the
keystone.conf/nova.conf/cinder.conf/glance.conf/neutron.conf. For example,
for keystone it is 'public_endpoint=https://api.example.org/identity/'.

Since keystoneauth 3.2.0 or commit
all internal client requests to the internal endpoints (for example,
openstack server list from controller node) fail with 404 error, because it
tries to do auto discovery at the http://controller:5000/v3. It gets
{"href": "https://api.example.org/identity/v3/", "rel": "self"} because of
the public_endpoint option, and then in function _combine_relative_url()
(keystoneauth1/discover.py:405) keystoneauth combines
http://controller:5000/ with the path from public href. So after auto
discovery attempt it goes to the wrong path

Before this commit openstackclient made auth request to the
https://api.example.org/identity/v3/auth/tokens (and it worked, because in
our deployment internal services and console clients can access this public
url). At best, we expect openstackclient always go to the

This problem partially could be solved by explicitly passing public
--os-auth-url https://api.example.org/identity/identity/v3 to the console
clients even if we want to use internal endpoints.

I found similiar bug in launchpad, but it haven't received any attention:

What could be done with this behavior of keystoneauth auto discovery?

- Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180511/913eaf97/attachment.html>

More information about the OpenStack-dev mailing list