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

Dolph Mathews dolph.mathews at gmail.com
Mon Jun 13 20:11:57 UTC 2016


On Fri, Jun 10, 2016 at 12:20 PM Clint Byrum <clint at fewbar.com> wrote:

> 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.
>
>
Please don't ever break the API - with or without a supposed "deprecation"
period.


> 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?
>

if I'm following your approach, then I should point out that we already
allow forward slashes in project names, so what breaks is any user that
already has forward slashes in their project names, but have no awareness
of, or intention to consume, hierarchical multitenancy.


>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160613/104833af/attachment.html>


More information about the OpenStack-dev mailing list