Possible confusion between auth_uri and auth_port
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Fix Released
|
High
|
Steven Hardy | ||
Sahara |
Fix Released
|
Medium
|
Unassigned | ||
devstack |
Fix Released
|
Undecided
|
Liyingjun | ||
openstack-manuals |
Fix Released
|
Undecided
|
Matt Kassawara |
Bug Description
Hello,
When Heat tries to contact Keystone, it reads the configuration flag keystone_
According to other openstack projects (See [1] [2] and [3]) auth_uri is only meant to be return to client as part of a HTTP-Header. The combination of auth_host and auth_port should be used to validate and ask new token from Keystone. auth_host should point to the admin url of keystone.
At the moment, Heat can't be install in an environment where the publicURL (the one referenced by auth_uri) is not reachable from the Heat engine. Other Openstack projects deals fine with this network topology.
This bug report relates to : https:/
[1] http://
[2] https:/
[3] https:/
Changed in heat: | |
milestone: | juno-1 → juno-2 |
Changed in heat: | |
milestone: | juno-2 → juno-3 |
Changed in heat: | |
milestone: | juno-3 → juno-rc1 |
Changed in heat: | |
assignee: | nobody → Steven Hardy (shardy) |
Changed in heat: | |
milestone: | juno-rc1 → kilo-1 |
Changed in heat: | |
milestone: | kilo-1 → kilo-2 |
Changed in heat: | |
milestone: | kilo-2 → kilo-3 |
Changed in sahara: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
milestone: | none → liberty-1 |
Changed in heat: | |
milestone: | kilo-3 → kilo-rc1 |
tags: | added: kilo-rc-potential |
Changed in heat: | |
milestone: | kilo-rc1 → next |
tags: | removed: kilo-rc-potential |
Changed in sahara: | |
milestone: | liberty-1 → liberty-2 |
Changed in sahara: | |
milestone: | liberty-2 → liberty-3 |
Changed in sahara: | |
milestone: | liberty-3 → liberty-rc1 |
Changed in sahara: | |
milestone: | liberty-rc1 → next |
Changed in heat: | |
milestone: | next → mitaka-1 |
importance: | Medium → High |
Changed in heat: | |
milestone: | mitaka-1 → mitaka-2 |
Changed in openstack-manuals: | |
assignee: | Steven Hardy (shardy) → Matt Kassawara (ionosphere80) |
tags: | removed: in-stable-liberty |
Changed in sahara: | |
milestone: | next → none |
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.