| 2016-11-21 05:07:36 |
Sam Morrison |
description |
Just upgraded to mitaka and we've found that eg. in glance we set
auth_url = http://127.0.0.1:35357
auth_uri = http://127.0.0.1:5000
(I've also tried adding /v3 on the end of these urls too)
But for some things auth_token seems to be trying to hit the endpoint that is in the catalog. The one I've caught is for downloading the revocation list.
The request ends up working but it takes ages because in our environment this host can't communicate to keystone via the endpoint in the auth catalog.
In the logs I see
WARNING keystoneauth.identity.base [-] Failed to contact the endpoint at https://keystone.example.org:35357/v2.0/ for discovery. Fallback to using that endpoint as the base url.
(also seems to use a v2.0 endpoint which we are trying to get rid of)
This worked in liberty but seems to have changed in mitaka.
versions
keystonemiddleware==4.4.1
keystoneauth1==2.4.1
python-keystoneclient==2.3.1 |
Just upgraded to mitaka and we've found that eg. in glance we configure auth_token like:
[keystone_authtoken]
auth_url = http://127.0.0.1:35357
auth_uri = http://127.0.0.1:5000
(I've also tried adding /v3 on the end of these urls too)
But for some things auth_token seems to be trying to hit the endpoint that is in the catalog. The one I've caught is for downloading the revocation list.
The request ends up working but it takes ages because in our environment this host can't communicate to keystone via the endpoint in the auth catalog.
In the logs I see
WARNING keystoneauth.identity.base [-] Failed to contact the endpoint at https://keystone.example.org:35357/v2.0/ for discovery. Fallback to using that endpoint as the base url.
(also seems to use a v2.0 endpoint which we are trying to get rid of)
This worked in liberty but seems to have changed in mitaka.
versions
keystonemiddleware==4.4.1
keystoneauth1==2.4.1
python-keystoneclient==2.3.1 |
|
