[openstack-dev] [keystone] Changing the project name uniqueness constraint

Clint Byrum clint at fewbar.com
Fri Jun 10 17:19:18 UTC 2016


Excerpts from Henry Nash's message of 2016-06-10 14:37:37 +0100:
> On further reflection, it seems to me that we can never simply enable either of these approaches in a single release. Even a v4.0 version of the API doesn’t help - since presumably a sever supporting v4 would want to be able to support v3.x for a signification time; and, already discussed, as soon as you allow multiple none-names to have the same name, you can no longer guarantee to support the current API.
> 
> Hence the only thing I think we can do (if we really do want to change the current functionality) is to do this over several releases with a typical deprecation cycle, e.g.
> 
> 1) At release 3.7 we allow you to (optionally) specify path names for auth….but make no changes to the uniqueness constraints. We also change the GET /auth/projects to return a path name. However, you can still auth exactly the way we do today (since there will always only be a single project of a given node-name). If however, you do auth without a path (to a project that isn’t a top level project), we log a warning to say this is deprecated (2 cycles, 4 cycles?)
> 2) If you connect with a 3.6 client, then you get the same as today for GET /auth/projects and cannot use a path name to auth.
> 3) At sometime in the future, we deprecate the “auth without a path” capability. We can debate as to whether this has to be a major release.
> 
> If we take this gradual approach, I would be pushing for the “relax project name constraints” approach…since I believe this leads to a cleaner eventual solution (and there is no particular advantage with the hierarchical naming approach) - and (until the end of the deprecation) there is no break to the existing API.
> 

This seems really complicated.

Why don't users just start using paths in project names, if they want
paths in project names?

And then in v3.7 you can allow them to specify paths relative to parent of
the user:

So just allow this always:

{"name": "finance/dev"}

And then add this later once users are aware of what the / means:

{"basename": "dev"}

What breaks by adding that?



More information about the OpenStack-dev mailing list