Comment 1 for bug 1300246

So there appear to be two issues here:

1. For both the core and contrib v2 keystoneclient wrapper, we use auth_uri for the auth_url passed into keystoneclient.

Arguably, as reported, this should instead use the auth_host/auth_port to connect to the admin endpoint for connections made as an admin (e.g when not using auth_url from the context, i.e using X-Auth-Url in standalone mode)

2. In the core keystoneclient wrapper, we override what is in the keystone catalog by passing auth_url and endpoint

This was to enable reliable access to v3 keystone functionality in environments where the catalog endpoints were versioned as v2.0. It may be that we can remove this now, as I believe work has been completed in keystoneclient to enable version discovery - hopefully this means we can move to just passing the auth_url and letting the client work out the endpoint from the catalog.

In both cases, my main concern is breaking existing functionality, we'll have to do some testing and figure out what works.

An alternative, simpler/less-risky solution is to provide a heat-specific configuration for admin connections to keystone. Arguably we're doing the wrong thing by reusing API configuration in the engine so perhaps having this (optionally) decoupled in the config file makes sense.