Open Stack

Excerpts from Dolph Mathews's message of 2016-06-13 20:11:57 +0000:
> 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.
> 

Pretty simple solution to that: they use the API they've always used,
which doesn't care about the hierarchy.