Hello. 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 https://github.com/openstack/keystoneauth/commit/8b8ff830e89923ca6862362a5d16e496a0c0093c 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 http://controller:5000/identity/v3/ 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 http://controller:5000/v3/ 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: https://bugs.launchpad.net/keystoneauth/+bug/1733052 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>