auth_token sems to ignore settings for auth_url and use catalog endpoint for keystone

[Sam Morrison]

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

[Lance Bragstad (lbragstad)]

Looks like this is related to keystoneauth [0] and not keystonemiddleware. So, just for clarification, your keystone endpoint in the catalog is not accessible from where the other services are. Instead the other services, specifically keystonemiddleware, must use some internal URL (http://127.0.0.1:5000 and http://127.0.0.1:35357 in your example) because they are not allowed to reach out to other services?

[0] https://github.com/openstack/keystoneauth/blob/b6f8648177f55423e76574db74dc511b0f89702d/keystoneauth1/identity/base.py#L231-L241

[Sam Morrison (sorrison)]

Yeah that's correct, worked fine in Liberty but with Mitaka it seems to ignore the setting (well not ignore the setting as it uses it initially to get the service catalogue I think and then from then uses the value in the service catalogue)

[Lance Bragstad (lbragstad)]

It looks like this is because keystoneauth attempts to discover the endpoint through the service catalog, rather than relying solely on configuration. The path to discovery also allows it to be smart about version discovery.

[Sam Morrison (sorrison)]

Just wondering why status is opinion?

Isn't it a bug since the config option is basically being ignored?

[Jamie Lennox (jamielennox)]

This is how auth_token middleware has worked for a while now. It uses the auth_url to authenticate with keystone and then the keystone url is determined from the catalog returned with the glance user's token.

auth_uri is unfortunately named but ends up in headers of 401 messages telling users where to go to authenticate.

Any situation where keystone.example.org is in your service catalog is going to/should end up with a broken cloud.

[Sam Morrison (sorrison)]

Yeah functionality changed between liberty -> mitaka

keystone.example.org was just an example :-)

Keystone and glance run on the same host so I want to point it to http://localhost as opposed to https://<load-balancer> (which in turn may just send it back to the same host)

Want to do this for efficiency reasons. No SSL for internal traffic and also doesn't need to go through the LB.

I had just assumed if I set in in the config to use a specific host it would use that. I don't see why it needs to get all complicated and try and discover what url to use when I already gave it one?

Any ideas on how I can achieve what I want?