| 2015-08-11 09:00:47 |
Henry Nash |
description |
According to the API spec, you must supply a domain for a user, group or project on create. You can do this either by specifying it explicitly in the object or by using a domain scoped token. Although the spec doesn't say this explicitly, one would expect an exception to be raised if you don't do either the these (e.g. try using a project scoped token). However, due to a long fixed bug (1283539) in a heat tempest, we actually fall back and try and use the default domain (which may still fail of course if you don't have a role on the default domain).
This fall back is neither in the spec nor is it sensible in the long run. We should raise a ValidationError in the situation when no domain is specified.
The only one concern I have is whether someone might have discovered this fall back in the field....and so there is an argument as to whether we should add deprecation warning if we detect this situation for a cycle? |
According to the API spec, you must supply a domain for a user, group or project on create. You can do this either by specifying it explicitly in the object or by using a domain scoped token. Although the spec doesn't say this explicitly, one would expect an exception to be raised if you don't do either the these (e.g. try using a project scoped token). However, due to a long fixed bug (1283539) in a heat tempest, we actually fall back and try and use the default domain (which may still fail of course if you don't have a role on the default domain).
This fall back is neither in the spec nor is it sensible in the long run. We should raise a ValidationError in the situation when no domain is specified.
The only one concern I have is whether someone might have discovered this fall back in the field....and so there is an argument as to whether we should add deprecation warning if we detect this situation for a cycle?
Whatever we decide, we should make the identity spec clearer as to what happens in this situation. |
|
