HTTP 400 creating heat stack if fails to create trust

[Matthew Edmonds]

When keystone trusts are disabled (CONF.trusts.enabled is False in keystone.conf), https://github.com/openstack/heat/blob/a41b5cf5eb2fcb3ab999c2eaee0838d5ca10f6e6/heat/engine/clients/os/keystone/heat_keystoneclient.py#L223 results in an HTTP 400 response. This is wrong, because there is nothing wrong with the request that was made (whereas 400 indicates caller error). Also, the reason message is inappropriate and unhelpful to the caller. And nothing useful is logged in heat's logs, which made this a real pain to debug.

The caller needs a response code/reason that indicates there is an issue with the service so that they go bug their operator to look into it, not waste time trying to figure out what is wrong with their request. And the operator needs something useful logged so they can distinguish this from other possible errors.

Note: it doesn't appear that HTTP 400 would be appropriate for any of the possible reasons for getting to the line of code referenced above, so having trusts disabled in keystone is but one way to hit this issue. Another configuration issue that might hit this line is if the trustee user does not exist, though this was not tested. All reasons for hitting this line should be analyzed and the appropriate error and logging may differ between them.

Found in Pike.

[Rabi Mishra (rabi)]

Yeah, HTTP 400 response is not correct in both the below cases
1. When trusts are disabled in keystone
2. trustee user does not exist.

The fact that keystone returns a 404 NotFound() in all these cases including that when the user does not have required 'trusts_delegated_roles'[2] does not help.

Probably the assumption earlier had been that if you've deferred_auth_method=trusts[1], trusts is expected to be enabled (which is the default) in keystone and the trustee user configured should exist.

I think change[3] tried to make the error more clear when the user does not have the required roles. However, it hides the other reasons for 404 from keystone.

Now that we inherit all roles when creating a trust context by default[4], we can probably
revert[3] rather than creating different errors for the user based on the error message from keystone.

[1] https://github.com/openstack/heat/blob/master/heat/common/config.py#L101
[2] https://github.com/openstack/heat/blob/master/heat/common/config.py#L117
[3] https://github.com/openstack/heat/commit/4e0538e2145b4db79c2489cbb1fb5e286a05ecd3
[4] https://github.com/openstack/heat/commit/aab01c00ff330d743fc15e97d7ae144eac5015bb

[Matthew Edmonds (edmondsw)]

If trusts_delegated_roles is set to something other than [], shouldn't heat attempt to create a trust with roles = the intersection of a) the roles on the token and b) the roles in trusts_delegated_roles? So that it would never ask for roles the user doesn't have, or roles that trusts_delegated_roles does not specify if that's being used as a filter.

Note: It is a keystone bug that keystone returns HTTP 404 if you try to create a trust with a role that you don't have. I've opened https://bugs.launchpad.net/keystone/+bug/1724685 though I don't think they will agree to fix that until they've added microversion support, since API guidelines say you can't change return codes without a microversion.

[Rabi Mishra (rabi)]

> If trusts_delegated_roles is set to something other than [],

I don't think so. If 'trusts_delegated_roles' is specified, heat assumes that those roles are needed to operate the stack on behalf of the user and should be a subset roles of the user that creates the stack.

All these are configuration issues (including trusts not being enabled) and operators should porbably know about those when providing orchestration service to the users.