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

[Henry Nash]

Hi

So following discussion on this, I have modified the spec to try and take 
account of the various concerns etc. See: 
https://review.openstack.org/#/c/318605/

For reference, here is an extract from this spec that summarizes the level of 
compatibility being proposed (A “3.6 client” refers to a Mitaka or earlier 
client speaking either directly to keystone server, or via our client 
libraries):

Summary of Compatibility Impacts
-

Here is a summary of the impact on clients when the server they are talking to
is upgraded to Newton:

* For a 3.6 client the names of project entities created before the server
  upgrade will not change (i.e. they will not contain the path).
* For either a 3.6 or a 3.7 client, any projects entities after the server is
  upgraded will be returned with names including the path.
* A 3.6 client will continue to be able to scope an auth to a project that
  existed before the upgrade without specifying a path, wherever that project
  exists in the hierarchy. To scope to a project created after the upgrade then
  the name (by definition) includes the path.
* Code written that extracts the project name from any of the project APIs that
  returns project entities, and then plugs that name into an auth scope will
  continue to work unmodifed, irrespective of the version of the client or
  server
* A 3.7 client will always see project names that include the path,
  irrespective of whether those projects were created before or after the
  server was upgraded. The implication of this is that once a client has
  upgraded to 3.7, then if the name of the project is being entered by a user
  (say for auth scope), then this name must always contain the path. While,
  technically, we could try to maintain the ability to access projects created
  before the server upgrade via their non-path name, it would get very
  confusing for users having to remember which projects you could or couldn't
  access this way.

Feel free to raise any concerns you have about the above.

Henry

> On 14 Jun 2016, at 16:22, Morgan Fainberg  wrote:
> 
> On Jun 14, 2016 00:46, "Henry Nash"  > wrote:
> 
> 
>> On 14 Jun 2016, at 07:34, Morgan Fainberg > > wrote:
>> 
>> 
>> 
>> On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash > > wrote:
>> So, I think it depends what level of compatibility we are aiming at. Let me 
>> articulate them, and we can agree which we want:
>> 
>> C1) In all version of the our APIs today (v2 and v3.0 to v3.6), you have 
>> been able to issue an auth request which used project/tenant name as the 
>> scoping directive (with v3 you need a domain component as well, but that’s 
>> not relevant for this discussion). In these APIs, we absolutely expect that 
>> if you could issue an auth request to. say project “test”, in, say, v3.X, 
>> then you could absolutely issue the exact same command at V3.(X+1). This has 
>> remained true, even when we introduced project hierarchies, i.e.: if I 
>> create:
>> 
>> /development/myproject/test
>> 
>> ...then I can still scope directly to the test project by simply specifying 
>> “test” as the project name (since, of course, all project names must still 
>> be unique in the domain). We never want to break this for so long as we 
>> formally support any APIs that once allowed this.
>> 
>> C2) To aid you issuing an auth request scoped by project (either name or 
>> id), we support a special API as part of the auth url (GET/auth/projects) 
>> that lists the projects the caller *could* scope to (i.e. those they have 
>> any kind of role on). You can take the “name” or “id” returned by this API 
>> and plug it directly into the auth request. Again for any API we currently 
>> support, we can’t break this.
>> 
>> C3) The name attribute of a project is its node-name in the hierarchy. If we 
>> decide to change this in a future API, we would not want a client using the 
>> existing API to get surprised and suddenly receive a path instead of the 
>> just the node-name (e.g. what if this was a UI of some type). 
>> 
>> Given all the above, there is no solution that can keep the above all true 
>> and allow more than one project of the same name in, say, v3.7 of the API. 
>> Even if we relaxed C2 and C2 -  C1 can never be guaranteed to be still 
>> supported. Neither of the original proposed solutions can address this 
>> (since it is a data modelling problem, not an API problem).
>> 
>> However, given that we will have, for the first time, the ability to 
>> microversion the Identity API starting with 3.7, there are things we can do 
>> to start us down this path. Let me re-articulate the options I am proposing:
>> 
>> Option 1A) In v3.7 we add a ‘path_name' attribute to a project entity, which 
>> is hence returned by any API that returns a project 

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

[Morgan Fainberg]

On Jun 14, 2016 00:46, "Henry Nash"  wrote:

>
> On 14 Jun 2016, at 07:34, Morgan Fainberg 
> wrote:
>
>
>
> On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash  wrote:
>
>> So, I think it depends what level of compatibility we are aiming at. Let
>> me articulate them, and we can agree which we want:
>>
>> C1) In all version of the our APIs today (v2 and v3.0 to v3.6), you have
>> been able to issue an auth request which used project/tenant name as the
>> scoping directive (with v3 you need a domain component as well, but that’s
>> not relevant for this discussion). In these APIs, we absolutely expect that
>> if you could issue an auth request to. say project “test”, in, say, v3.X,
>> then you could absolutely issue the exact same command at V3.(X+1). This
>> has remained true, even when we introduced project hierarchies, i.e.: if I
>> create:
>>
>> /development/myproject/test
>>
>> ...then I can still scope directly to the test project by simply
>> specifying “test” as the project name (since, of course, all project names
>> must still be unique in the domain). We never want to break this for so
>> long as we formally support any APIs that once allowed this.
>>
>> C2) To aid you issuing an auth request scoped by project (either name or
>> id), we support a special API as part of the auth url (GET/auth/projects)
>> that lists the projects the caller *could* scope to (i.e. those they have
>> any kind of role on). You can take the “name” or “id” returned by this API
>> and plug it directly into the auth request. Again for any API we currently
>> support, we can’t break this.
>>
>> C3) The name attribute of a project is its node-name in the hierarchy. If
>> we decide to change this in a future API, we would not want a client using
>> the existing API to get surprised and suddenly receive a path instead of
>> the just the node-name (e.g. what if this was a UI of some type).
>>
>> Given all the above, there is no solution that can keep the above all
>> true and allow more than one project of the same name in, say, v3.7 of the
>> API. Even if we relaxed C2 and C2 -  C1 can never be guaranteed to be still
>> supported. Neither of the original proposed solutions can address this
>> (since it is a data modelling problem, not an API problem).
>>
>> However, given that we will have, for the first time, the ability to
>> microversion the Identity API starting with 3.7, there are things we can do
>> to start us down this path. Let me re-articulate the options I am proposing:
>>
>> Option 1A) In v3.7 we add a ‘path_name' attribute to a project entity,
>> which is hence returned by any API that returns a project entity. The
>> ‘path_name' attribute will contain the full path name, including the
>> project itself. (Note that clients speaking 3.6 and earlier will not see
>> this new attribute). Further, for clients speaking 3.7 and later, we add
>> support to allow a ‘path_name' (as an alternative to ‘name' or ‘id') to be
>> used in auth scoping. We do not (yet) relax any uniqueness constraints, but
>> mark API 3.6 and earlier as deprecated, as well as using the ‘name’
>> attribute in the auth request. (we still support all these, we just mark
>> them as deprecated). At some time in the future (e.g. 3.8), we remove
>> support for using ‘name’ for auth, insisting on the use of ‘path_name’
>> instead. Sometime later (e.g. 3.10) we remove support for 3.8 and earlier.
>> Then and only then, do we relax the uniqueness constraint allowing projects
>> with duplicate node-names (but with different parents).
>>
>> Option 1B) The same as 1A, but we insist on path_name use in auth in v3.7
>> (i.e. no grace-period for still using just ’name', instead relying on the
>> fact that 3.6 clients will still work just fine). Then later (e.g. perhaps
>> v3.9), we remove support for v3.6 and before…and relax the uniqueness
>> constraint.
>>
>>
> Let say the assumption that we are "removing" 3.6 should be stopped right
> now. I don't want to embark on the "when we remove this" as an option or
> discuss how we remove previous versions. Please lets assume for the sake of
> this conversation unless we have a major API version increase (API v4 and
> do not expose v4 projects via v3 API) this is unlikely happen. Deprecated
> or not, planning the removal of current supported API auth functionality is
> not on the table. In v3 we are not going to "relax" the uniqueness
> constraint in the foreseeable future. Just assume v3.6 is going to live
> forever for now and we can revisit when/if limits on microversion lower
> bounds is addressed in OpenStack with TC direction/guidance.
>
>
> Why should we not be able to remove a microversion (once keystone properly
> supports microversioning, as we will in 3.7)? The cross project guidelines
> (see:
> https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html),
> clearly gives example of how we would support the dropping of 

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

[Henry Nash]

> On 14 Jun 2016, at 07:34, Morgan Fainberg  wrote:
> 
> 
> 
> On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash  > wrote:
> So, I think it depends what level of compatibility we are aiming at. Let me 
> articulate them, and we can agree which we want:
> 
> C1) In all version of the our APIs today (v2 and v3.0 to v3.6), you have been 
> able to issue an auth request which used project/tenant name as the scoping 
> directive (with v3 you need a domain component as well, but that’s not 
> relevant for this discussion). In these APIs, we absolutely expect that if 
> you could issue an auth request to. say project “test”, in, say, v3.X, then 
> you could absolutely issue the exact same command at V3.(X+1). This has 
> remained true, even when we introduced project hierarchies, i.e.: if I create:
> 
> /development/myproject/test
> 
> ...then I can still scope directly to the test project by simply specifying 
> “test” as the project name (since, of course, all project names must still be 
> unique in the domain). We never want to break this for so long as we formally 
> support any APIs that once allowed this.
> 
> C2) To aid you issuing an auth request scoped by project (either name or id), 
> we support a special API as part of the auth url (GET/auth/projects) that 
> lists the projects the caller *could* scope to (i.e. those they have any kind 
> of role on). You can take the “name” or “id” returned by this API and plug it 
> directly into the auth request. Again for any API we currently support, we 
> can’t break this.
> 
> C3) The name attribute of a project is its node-name in the hierarchy. If we 
> decide to change this in a future API, we would not want a client using the 
> existing API to get surprised and suddenly receive a path instead of the just 
> the node-name (e.g. what if this was a UI of some type). 
> 
> Given all the above, there is no solution that can keep the above all true 
> and allow more than one project of the same name in, say, v3.7 of the API. 
> Even if we relaxed C2 and C2 -  C1 can never be guaranteed to be still 
> supported. Neither of the original proposed solutions can address this (since 
> it is a data modelling problem, not an API problem).
> 
> However, given that we will have, for the first time, the ability to 
> microversion the Identity API starting with 3.7, there are things we can do 
> to start us down this path. Let me re-articulate the options I am proposing:
> 
> Option 1A) In v3.7 we add a ‘path_name' attribute to a project entity, which 
> is hence returned by any API that returns a project entity. The ‘path_name' 
> attribute will contain the full path name, including the project itself. 
> (Note that clients speaking 3.6 and earlier will not see this new attribute). 
> Further, for clients speaking 3.7 and later, we add support to allow a 
> ‘path_name' (as an alternative to ‘name' or ‘id') to be used in auth scoping. 
> We do not (yet) relax any uniqueness constraints, but mark API 3.6 and 
> earlier as deprecated, as well as using the ‘name’ attribute in the auth 
> request. (we still support all these, we just mark them as deprecated). At 
> some time in the future (e.g. 3.8), we remove support for using ‘name’ for 
> auth, insisting on the use of ‘path_name’ instead. Sometime later (e.g. 3.10) 
> we remove support for 3.8 and earlier. Then and only then, do we relax the 
> uniqueness constraint allowing projects with duplicate node-names (but with 
> different parents).
> 
> Option 1B) The same as 1A, but we insist on path_name use in auth in v3.7 
> (i.e. no grace-period for still using just ’name', instead relying on the 
> fact that 3.6 clients will still work just fine). Then later (e.g. perhaps 
> v3.9), we remove support for v3.6 and before…and relax the uniqueness 
> constraint.
> 
> 
> Let say the assumption that we are "removing" 3.6 should be stopped right 
> now. I don't want to embark on the "when we remove this" as an option or 
> discuss how we remove previous versions. Please lets assume for the sake of 
> this conversation unless we have a major API version increase (API v4 and do 
> not expose v4 projects via v3 API) this is unlikely happen. Deprecated or 
> not, planning the removal of current supported API auth functionality is not 
> on the table. In v3 we are not going to "relax" the uniqueness constraint in 
> the foreseeable future. Just assume v3.6 is going to live forever for now and 
> we can revisit when/if limits on microversion lower bounds is addressed in 
> OpenStack with TC direction/guidance.

Why should we not be able to remove a microversion (once keystone properly 
supports microversioning, as we will in 3.7)? The cross project guidelines 
(see: 
https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
 
),
 clearly gives 

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

[Morgan Fainberg]

On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash  wrote:

> So, I think it depends what level of compatibility we are aiming at. Let
> me articulate them, and we can agree which we want:
>
> C1) In all version of the our APIs today (v2 and v3.0 to v3.6), you have
> been able to issue an auth request which used project/tenant name as the
> scoping directive (with v3 you need a domain component as well, but that’s
> not relevant for this discussion). In these APIs, we absolutely expect that
> if you could issue an auth request to. say project “test”, in, say, v3.X,
> then you could absolutely issue the exact same command at V3.(X+1). This
> has remained true, even when we introduced project hierarchies, i.e.: if I
> create:
>
> /development/myproject/test
>
> ...then I can still scope directly to the test project by simply
> specifying “test” as the project name (since, of course, all project names
> must still be unique in the domain). We never want to break this for so
> long as we formally support any APIs that once allowed this.
>
> C2) To aid you issuing an auth request scoped by project (either name or
> id), we support a special API as part of the auth url (GET/auth/projects)
> that lists the projects the caller *could* scope to (i.e. those they have
> any kind of role on). You can take the “name” or “id” returned by this API
> and plug it directly into the auth request. Again for any API we currently
> support, we can’t break this.
>
> C3) The name attribute of a project is its node-name in the hierarchy. If
> we decide to change this in a future API, we would not want a client using
> the existing API to get surprised and suddenly receive a path instead of
> the just the node-name (e.g. what if this was a UI of some type).
>
> Given all the above, there is no solution that can keep the above all true
> and allow more than one project of the same name in, say, v3.7 of the API.
> Even if we relaxed C2 and C2 -  C1 can never be guaranteed to be still
> supported. Neither of the original proposed solutions can address this
> (since it is a data modelling problem, not an API problem).
>
> However, given that we will have, for the first time, the ability to
> microversion the Identity API starting with 3.7, there are things we can do
> to start us down this path. Let me re-articulate the options I am proposing:
>
> Option 1A) In v3.7 we add a ‘path_name' attribute to a project entity,
> which is hence returned by any API that returns a project entity. The
> ‘path_name' attribute will contain the full path name, including the
> project itself. (Note that clients speaking 3.6 and earlier will not see
> this new attribute). Further, for clients speaking 3.7 and later, we add
> support to allow a ‘path_name' (as an alternative to ‘name' or ‘id') to be
> used in auth scoping. We do not (yet) relax any uniqueness constraints, but
> mark API 3.6 and earlier as deprecated, as well as using the ‘name’
> attribute in the auth request. (we still support all these, we just mark
> them as deprecated). At some time in the future (e.g. 3.8), we remove
> support for using ‘name’ for auth, insisting on the use of ‘path_name’
> instead. Sometime later (e.g. 3.10) we remove support for 3.8 and earlier.
> Then and only then, do we relax the uniqueness constraint allowing projects
> with duplicate node-names (but with different parents).
>
> Option 1B) The same as 1A, but we insist on path_name use in auth in v3.7
> (i.e. no grace-period for still using just ’name', instead relying on the
> fact that 3.6 clients will still work just fine). Then later (e.g. perhaps
> v3.9), we remove support for v3.6 and before…and relax the uniqueness
> constraint.
>
>
Let say the assumption that we are "removing" 3.6 should be stopped right
now. I don't want to embark on the "when we remove this" as an option or
discuss how we remove previous versions. Please lets assume for the sake of
this conversation unless we have a major API version increase (API v4 and
do not expose v4 projects via v3 API) this is unlikely happen. Deprecated
or not, planning the removal of current supported API auth functionality is
not on the table. In v3 we are not going to "relax" the uniqueness
constraint in the foreseeable future. Just assume v3.6 is going to live
forever for now and we can revisit when/if limits on microversion lower
bounds is addressed in OpenStack with TC direction/guidance.


> Option 2A) In 3.7 the meaning of the ‘name' attribute of project entity is
> redefined to be the full path name (note that clients speaking 3.6 will
> continue to see ’name’ just be the node-name without a path). We do not
> (yet) relax any uniqueness constraints. For clients speaking 3.7 and later,
> we return the full path name where the project entity ‘name’ attribute is
> returned. For auth, we allow a full path name to specified in the ‘name’
> scope attribute - but we also still support just a name without a path
> (which we can guarantee to 

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

[Henry Nash]

So, I think it depends what level of compatibility we are aiming at. Let me 
articulate them, and we can agree which we want:

C1) In all version of the our APIs today (v2 and v3.0 to v3.6), you have been 
able to issue an auth request which used project/tenant name as the scoping 
directive (with v3 you need a domain component as well, but that’s not relevant 
for this discussion). In these APIs, we absolutely expect that if you could 
issue an auth request to. say project “test”, in, say, v3.X, then you could 
absolutely issue the exact same command at V3.(X+1). This has remained true, 
even when we introduced project hierarchies, i.e.: if I create:

/development/myproject/test

...then I can still scope directly to the test project by simply specifying 
“test” as the project name (since, of course, all project names must still be 
unique in the domain). We never want to break this for so long as we formally 
support any APIs that once allowed this.

C2) To aid you issuing an auth request scoped by project (either name or id), 
we support a special API as part of the auth url (GET/auth/projects) that lists 
the projects the caller *could* scope to (i.e. those they have any kind of role 
on). You can take the “name” or “id” returned by this API and plug it directly 
into the auth request. Again for any API we currently support, we can’t break 
this.

C3) The name attribute of a project is its node-name in the hierarchy. If we 
decide to change this in a future API, we would not want a client using the 
existing API to get surprised and suddenly receive a path instead of the just 
the node-name (e.g. what if this was a UI of some type). 

Given all the above, there is no solution that can keep the above all true and 
allow more than one project of the same name in, say, v3.7 of the API. Even if 
we relaxed C2 and C2 -  C1 can never be guaranteed to be still supported. 
Neither of the original proposed solutions can address this (since it is a data 
modelling problem, not an API problem).

However, given that we will have, for the first time, the ability to 
microversion the Identity API starting with 3.7, there are things we can do to 
start us down this path. Let me re-articulate the options I am proposing:

Option 1A) In v3.7 we add a ‘path_name' attribute to a project entity, which is 
hence returned by any API that returns a project entity. The ‘path_name' 
attribute will contain the full path name, including the project itself. (Note 
that clients speaking 3.6 and earlier will not see this new attribute). 
Further, for clients speaking 3.7 and later, we add support to allow a 
‘path_name' (as an alternative to ‘name' or ‘id') to be used in auth scoping. 
We do not (yet) relax any uniqueness constraints, but mark API 3.6 and earlier 
as deprecated, as well as using the ‘name’ attribute in the auth request. (we 
still support all these, we just mark them as deprecated). At some time in the 
future (e.g. 3.8), we remove support for using ‘name’ for auth, insisting on 
the use of ‘path_name’ instead. Sometime later (e.g. 3.10) we remove support 
for 3.8 and earlier. Then and only then, do we relax the uniqueness constraint 
allowing projects with duplicate node-names (but with different parents).

Option 1B) The same as 1A, but we insist on path_name use in auth in v3.7 (i.e. 
no grace-period for still using just ’name', instead relying on the fact that 
3.6 clients will still work just fine). Then later (e.g. perhaps v3.9), we 
remove support for v3.6 and before…and relax the uniqueness constraint.

Option 2A) In 3.7 the meaning of the ‘name' attribute of project entity is 
redefined to be the full path name (note that clients speaking 3.6 will 
continue to see ’name’ just be the node-name without a path). We do not (yet) 
relax any uniqueness constraints. For clients speaking 3.7 and later, we return 
the full path name where the project entity ‘name’ attribute is returned. For 
auth, we allow a full path name to specified in the ‘name’ scope attribute - 
but we also still support just a name without a path (which we can guarantee to 
honour, since, so far, we haven’t relaxed the uniqueness constraint - however 
we mark that support as deprecated). At some time in the future (e.g. 3.8), we 
remove support for using an un-pathed ‘name’ for auth. Sometime later (e..g. 
3.10) we remove support for 3.8 and earlier. Then and only then, do we relax 
the uniqueness constraint allowing projects with duplicate node-names (but with 
different parents).

Option 2B) The same as 2A, but we insist on using ‘name’ with a full path use 
in auth in v3.7 (i.e. no grace-period for still using an un-pathed  ’name', 
instead relying on the fact that 3.6 clients will still work just fine). Then 
later (e.g. perhaps v3.9), we remove support for v3.6 and before…and relax the 
uniqueness constraint.

The downside for option 2A and 2B is that a client must do work to not be 
“surprised” by 3.7 (since the ‘name’ attribute of a 

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

[Clint Byrum]

Excerpts from Dolph Mathews's message of 2016-06-13 20:11:57 +:
> On Fri, Jun 10, 2016 at 12:20 PM Clint Byrum  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.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dolph Mathews]

On Fri, Jun 10, 2016 at 12:20 PM Clint Byrum  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
-Dolph
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Morgan Fainberg]

On Fri, Jun 10, 2016 at 6:37 AM, Henry Nash  wrote:

> 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.
>
> Henry
>
>
How do you handle relaxed project name constraints without completely
breaking 3.6 auth - regardless of future microversion that requires the
full path. This is a major api change and will result in very complex
matrix of project name mapping (old projects that can be accessed without
the full path, new that must always have the path)?

Simply put, I do not see relaxing project name constraints as viable
without a major API change and projects that simply are unavailable for
scoping a token to under the base api version (pre-microversions) of 3.6

I am certain that if all projects post API version 3.6 are created with the
full-path name only and that is how they are represented to the user for
auth, we get both things for free. Old projects pre-full-path would need
optional compatibility for deconstructing a full-path for them.  Basically
you end up with "path" and "name", in old projects these differ, in new
projects they are the same.  No conflicts, not breaking "currently working
auth", no "major API version" needed.

--Morgan


> On 7 Jun 2016, at 09:47, Henry Nash  wrote:
>
> OK, so thanks for the feedback - understand the message.
>
> However, in terms of compatibility, the one thing that concerns me about
> the hierarchical naming approach is that even with microversioing, we might
> still surprise a client. An unmodified client (i.e. doesn’t understand 3.7)
> would still see a change in the data being returned (the project names have
> suddenly become full path names). We have to return this even if they don’t
> ask for 3.7, since otherwise there is no difference between this approach
> and relaxing the project naming in terms of trying to prevent auth
> breakages.
>
> In more detail:
>
> 1) Both approaches were planned to return the path name (instead of the
> node name) in GET /auth/projects - i.e. the API you are meant to use to
> find out what you can scope to
> 2) Both approaches were planned to accept the path name in the auth
> request block
> 3) The difference in hierarchical naming is the if I do a regular GET
> /project(s) I also see the full path name as the “project name”
>
> if we don’t do 3), then code that somehow authenticates, and then uses the
> regular GET /project(s) calls to find a project name and then re-scopes (or
> re-auths) to that name, will fail if the project they want is not a top
> level project. However, the flip side is that if there is code that uses
> these same calls to, say, display projects to the user (e.g. a home grown
> UI) - then it might get confused until it supports 3.7 (i.e. asking for the
> old microversion won’t help it) since all the names include the
> hierarchical path.
>
> Just want to make sure we understand the implications….
>
> Henry
>
> On 4 Jun 2016, at 08:34, Monty Taylor  wrote:
>
> On 06/04/2016 01:53 AM, Morgan Fainberg wrote:
>
>
> On Jun 3, 2016 12:42, "Lance Bragstad"  >> wrote:
>
>
>
>
> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash 
> >> wrote:
>
>
>
> On 3 Jun 2016, at 16:38, Lance Bragstad 

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

[Clint Byrum]

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?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Nash]

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.

Henry
> On 7 Jun 2016, at 09:47, Henry Nash  wrote:
> 
> OK, so thanks for the feedback - understand the message.
> 
> However, in terms of compatibility, the one thing that concerns me about the 
> hierarchical naming approach is that even with microversioing, we might still 
> surprise a client. An unmodified client (i.e. doesn’t understand 3.7) would 
> still see a change in the data being returned (the project names have 
> suddenly become full path names). We have to return this even if they don’t 
> ask for 3.7, since otherwise there is no difference between this approach and 
> relaxing the project naming in terms of trying to prevent auth breakages.
> 
> In more detail:
> 
> 1) Both approaches were planned to return the path name (instead of the node 
> name) in GET /auth/projects - i.e. the API you are meant to use to find out 
> what you can scope to
> 2) Both approaches were planned to accept the path name in the auth request 
> block
> 3) The difference in hierarchical naming is the if I do a regular GET 
> /project(s) I also see the full path name as the “project name”
> 
> if we don’t do 3), then code that somehow authenticates, and then uses the 
> regular GET /project(s) calls to find a project name and then re-scopes (or 
> re-auths) to that name, will fail if the project they want is not a top level 
> project. However, the flip side is that if there is code that uses these same 
> calls to, say, display projects to the user (e.g. a home grown UI) - then it 
> might get confused until it supports 3.7 (i.e. asking for the old 
> microversion won’t help it) since all the names include the hierarchical path.
> 
> Just want to make sure we understand the implications….
> 
> Henry
> 
>> On 4 Jun 2016, at 08:34, Monty Taylor > > wrote:
>> 
>> On 06/04/2016 01:53 AM, Morgan Fainberg wrote:
>>> 
>>> On Jun 3, 2016 12:42, "Lance Bragstad" >> 
>>> >> wrote:
 
 
 
 On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash 
>>> >> wrote:
> 
> 
>> On 3 Jun 2016, at 16:38, Lance Bragstad > 
>>> >> wrote:
>> 
>> 
>> 
>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash > 
>>> >> wrote:
>>> 
>>> 
 On 3 Jun 2016, at 01:22, Adam Young 
>>> >> wrote:
 
 On 06/02/2016 07:22 PM, Henry Nash wrote:
> 
> Hi
> 
> As you know, I have been working on specs that change the way we
>>> handle the uniqueness of project names in Newton. The goal of this is to
>>> better support project hierarchies, which as they stand today are
>>> restrictive in that all project names within a domain must be unique,
>>> irrespective of where in the hierarchy that projects sits (unlike, say,
>>> the unix directory 

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

[Henry Nash]

OK, so thanks for the feedback - understand the message.

However, in terms of compatibility, the one thing that concerns me about the 
hierarchical naming approach is that even with microversioing, we might still 
surprise a client. An unmodified client (i.e. doesn’t understand 3.7) would 
still see a change in the data being returned (the project names have suddenly 
become full path names). We have to return this even if they don’t ask for 3.7, 
since otherwise there is no difference between this approach and relaxing the 
project naming in terms of trying to prevent auth breakages.

In more detail:

1) Both approaches were planned to return the path name (instead of the node 
name) in GET /auth/projects - i.e. the API you are meant to use to find out 
what you can scope to
2) Both approaches were planned to accept the path name in the auth request 
block
3) The difference in hierarchical naming is the if I do a regular GET 
/project(s) I also see the full path name as the “project name”

if we don’t do 3), then code that somehow authenticates, and then uses the 
regular GET /project(s) calls to find a project name and then re-scopes (or 
re-auths) to that name, will fail if the project they want is not a top level 
project. However, the flip side is that if there is code that uses these same 
calls to, say, display projects to the user (e.g. a home grown UI) - then it 
might get confused until it supports 3.7 (i.e. asking for the old microversion 
won’t help it) since all the names include the hierarchical path.

Just want to make sure we understand the implications….

Henry

> On 4 Jun 2016, at 08:34, Monty Taylor  wrote:
> 
> On 06/04/2016 01:53 AM, Morgan Fainberg wrote:
>> 
>> On Jun 3, 2016 12:42, "Lance Bragstad" > 
>> >> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash >> 
>> >> wrote:
 
 
> On 3 Jun 2016, at 16:38, Lance Bragstad  
>> >> wrote:
> 
> 
> 
> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  
>> >> wrote:
>> 
>> 
>>> On 3 Jun 2016, at 01:22, Adam Young >> 
>> >> wrote:
>>> 
>>> On 06/02/2016 07:22 PM, Henry Nash wrote:
 
 Hi
 
 As you know, I have been working on specs that change the way we
>> handle the uniqueness of project names in Newton. The goal of this is to
>> better support project hierarchies, which as they stand today are
>> restrictive in that all project names within a domain must be unique,
>> irrespective of where in the hierarchy that projects sits (unlike, say,
>> the unix directory structure where a node name only has to be unique
>> within its parent). Such a restriction is particularly problematic when
>> enterprise start modelling things like test, QA and production as
>> branches of a project hierarchy, e.g.:
 
 /mydivsion/projectA/dev
 /mydivsion/projectA/QA
 /mydivsion/projectA/prod
 /mydivsion/projectB/dev
 /mydivsion/projectB/QA
 /mydivsion/projectB/prod
 
 Obviously the idea of a project name (née tenant) being unique
>> has been around since near the beginning of (OpenStack) time, so we must
>> be cautions. There are two alternative specs proposed:
 
 1) Relax project name
>> constraints: https://review.openstack.org/#/c/310048/ 
 2) Hierarchical project
>> naming: https://review.openstack.org/#/c/318605/
 
 First, here’s what they have in common:
 
 a) They both solve the above problem
 b) They both allow an authorization scope to use a path rather
>> than just a simple name, hence allowing you to address a project
>> anywhere in the hierarchy
 c) Neither have any impact if you are NOT using a hierarchy -
>> i.e. if you just have a flat layer of projects in a domain, then they
>> have no API or semantic impact (since both ensure that a project’s name
>> must still be unique within a parent)
 
 Here’s how the differ:
 
 - Relax project name constraints (1), keeps the meaning of the
>> ‘name’ attribute of a project to be its node-name in the hierarchy, but
>> formally relaxes the uniqueness constraint to say that it only has to be
>> unique within its parent. In other words, let’s really model this a bit
>> like a unix directory tree.
> 
> I think I lean towards relaxing the project name constraint. The
>> reason is because we already 

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

[Monty Taylor]

On 06/04/2016 01:53 AM, Morgan Fainberg wrote:
> 
> On Jun 3, 2016 12:42, "Lance Bragstad"  > wrote:
>>
>>
>>
>> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash  > wrote:
>>>
>>>
 On 3 Jun 2016, at 16:38, Lance Bragstad  > wrote:



 On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  > wrote:
>
>
>> On 3 Jun 2016, at 01:22, Adam Young  > wrote:
>>
>> On 06/02/2016 07:22 PM, Henry Nash wrote:
>>>
>>> Hi
>>>
>>> As you know, I have been working on specs that change the way we
> handle the uniqueness of project names in Newton. The goal of this is to
> better support project hierarchies, which as they stand today are
> restrictive in that all project names within a domain must be unique,
> irrespective of where in the hierarchy that projects sits (unlike, say,
> the unix directory structure where a node name only has to be unique
> within its parent). Such a restriction is particularly problematic when
> enterprise start modelling things like test, QA and production as
> branches of a project hierarchy, e.g.:
>>>
>>> /mydivsion/projectA/dev
>>> /mydivsion/projectA/QA
>>> /mydivsion/projectA/prod
>>> /mydivsion/projectB/dev
>>> /mydivsion/projectB/QA
>>> /mydivsion/projectB/prod
>>>
>>> Obviously the idea of a project name (née tenant) being unique
> has been around since near the beginning of (OpenStack) time, so we must
> be cautions. There are two alternative specs proposed:
>>>
>>> 1) Relax project name
> constraints: https://review.openstack.org/#/c/310048/ 
>>> 2) Hierarchical project
> naming: https://review.openstack.org/#/c/318605/
>>>
>>> First, here’s what they have in common:
>>>
>>> a) They both solve the above problem
>>> b) They both allow an authorization scope to use a path rather
> than just a simple name, hence allowing you to address a project
> anywhere in the hierarchy
>>> c) Neither have any impact if you are NOT using a hierarchy -
> i.e. if you just have a flat layer of projects in a domain, then they
> have no API or semantic impact (since both ensure that a project’s name
> must still be unique within a parent)
>>>
>>> Here’s how the differ:
>>>
>>> - Relax project name constraints (1), keeps the meaning of the
> ‘name’ attribute of a project to be its node-name in the hierarchy, but
> formally relaxes the uniqueness constraint to say that it only has to be
> unique within its parent. In other words, let’s really model this a bit
> like a unix directory tree.

 I think I lean towards relaxing the project name constraint. The
> reason is because we already expose `domain_id`, `parent_id`, and `name`
> of a project. By relaxing the constraint we can give the user everything
> the need to know about a project without really changing any of these.
> When using 3.7, you know what domain your project is in, you know the
> identifier of the parent project, and you know that your project name is
> unique within the parent.  
>>>
>>> - Hierarchical project naming (2), formally changes the meaning
> of the ‘name’ attribute to include the path to the node as well as the
> node name, and hence ensures that the (new) value of the name attribute
> remains unique.

 Do we intend to *store* the full path as the name, or just build it
> out on demand? If we do store the full path, we will have to think about
> our current data model since the depth of the organization or domain
> would be limited by the max possible name length. Will performance be
> something to think about building the full path on every request?   
>>>
>>> I now mention this issue in the spec for hierarchical project naming
> (the relax naming approach does not suffer this issue). As you say,
> we’ll have to change the DB (today it is only 64 chars) if we do store
> the full path . This is slightly problematic since the maximum depth of
> hierarchy is controlled by a config option, and hence could be changed.
> We will absolutely have be able to build the path on-the-fly in order to
> support legacy drivers (who won’t be able to store more than 64 chars).
> We may need to do some performance tests to ascertain if we can get away
> with building the path on-the-fly in all cases and avoid changing the
> table.  One additional point is that, of course, the API will return
> this path whenever it returns a project - so clients will need to be
> aware of this increase in size. 
>>
>>
>> These are all good points that continue to push me towards relaxing
> the project naming constraint :) 
>>>
>>>
>>> While whichever approach we chose would only be included in a new
> microversion (3.7) of the Identity API, although some relevant 

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

[Henry Nash]

Both proposals allow you to provide a path as the project name in auth (so you 
can still use domain name + project path name). The difference between the two 
is whether you formally represent the path in the name attribute of a project, 
i.e. when it is returned by GET /project.  The relax name constraints works 
like the linux dir tree. If I do an ‘ls’ I get the node names of the all 
entities in that directory, but I can still do 'cd /a/b/c' to jump right to 
where I want.

Henry
> On 3 Jun 2016, at 23:53, Morgan Fainberg  wrote:
> 
> 
> On Jun 3, 2016 12:42, "Lance Bragstad"  > wrote:
> >
> >
> >
> > On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash  > > wrote:
> >>
> >>
> >>> On 3 Jun 2016, at 16:38, Lance Bragstad  >>> > wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  >>> > wrote:
> 
> 
> > On 3 Jun 2016, at 01:22, Adam Young  > > wrote:
> >
> > On 06/02/2016 07:22 PM, Henry Nash wrote:
> >>
> >> Hi
> >>
> >> As you know, I have been working on specs that change the way we 
> >> handle the uniqueness of project names in Newton. The goal of this is 
> >> to better support project hierarchies, which as they stand today are 
> >> restrictive in that all project names within a domain must be unique, 
> >> irrespective of where in the hierarchy that projects sits (unlike, 
> >> say, the unix directory structure where a node name only has to be 
> >> unique within its parent). Such a restriction is particularly 
> >> problematic when enterprise start modelling things like test, QA and 
> >> production as branches of a project hierarchy, e.g.:
> >>
> >> /mydivsion/projectA/dev
> >> /mydivsion/projectA/QA
> >> /mydivsion/projectA/prod
> >> /mydivsion/projectB/dev
> >> /mydivsion/projectB/QA
> >> /mydivsion/projectB/prod
> >>
> >> Obviously the idea of a project name (née tenant) being unique has 
> >> been around since near the beginning of (OpenStack) time, so we must 
> >> be cautions. There are two alternative specs proposed:
> >>
> >> 1) Relax project name constraints: 
> >> https://review.openstack.org/#/c/310048/ 
> >>  
> >> 2) Hierarchical project naming: 
> >> https://review.openstack.org/#/c/318605/ 
> >> 
> >>
> >> First, here’s what they have in common:
> >>
> >> a) They both solve the above problem
> >> b) They both allow an authorization scope to use a path rather than 
> >> just a simple name, hence allowing you to address a project anywhere 
> >> in the hierarchy
> >> c) Neither have any impact if you are NOT using a hierarchy - i.e. if 
> >> you just have a flat layer of projects in a domain, then they have no 
> >> API or semantic impact (since both ensure that a project’s name must 
> >> still be unique within a parent)
> >>
> >> Here’s how the differ:
> >>
> >> - Relax project name constraints (1), keeps the meaning of the ‘name’ 
> >> attribute of a project to be its node-name in the hierarchy, but 
> >> formally relaxes the uniqueness constraint to say that it only has to 
> >> be unique within its parent. In other words, let’s really model this a 
> >> bit like a unix directory tree.
> >>>
> >>> I think I lean towards relaxing the project name constraint. The reason 
> >>> is because we already expose `domain_id`, `parent_id`, and `name` of a 
> >>> project. By relaxing the constraint we can give the user everything the 
> >>> need to know about a project without really changing any of these. When 
> >>> using 3.7, you know what domain your project is in, you know the 
> >>> identifier of the parent project, and you know that your project name is 
> >>> unique within the parent.  
> >>
> >> - Hierarchical project naming (2), formally changes the meaning of the 
> >> ‘name’ attribute to include the path to the node as well as the node 
> >> name, and hence ensures that the (new) value of the name attribute 
> >> remains unique.
> >>>
> >>> Do we intend to *store* the full path as the name, or just build it out 
> >>> on demand? If we do store the full path, we will have to think about our 
> >>> current data model since the depth of the organization or domain would be 
> >>> limited by the max possible name length. Will performance be something to 
> >>> think about building the full path on every request?   
> >>
> >> I now mention this issue in the spec for hierarchical project naming (the 
> >> relax naming approach does not suffer this issue). As you say, we’ll have 
> >> 

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

[Morgan Fainberg]

On Jun 3, 2016 12:42, "Lance Bragstad"  wrote:
>
>
>
> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash  wrote:
>>
>>
>>> On 3 Jun 2016, at 16:38, Lance Bragstad  wrote:
>>>
>>>
>>>
>>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  wrote:


> On 3 Jun 2016, at 01:22, Adam Young  wrote:
>
> On 06/02/2016 07:22 PM, Henry Nash wrote:
>>
>> Hi
>>
>> As you know, I have been working on specs that change the way we
handle the uniqueness of project names in Newton. The goal of this is to
better support project hierarchies, which as they stand today are
restrictive in that all project names within a domain must be unique,
irrespective of where in the hierarchy that projects sits (unlike, say, the
unix directory structure where a node name only has to be unique within its
parent). Such a restriction is particularly problematic when enterprise
start modelling things like test, QA and production as branches of a
project hierarchy, e.g.:
>>
>> /mydivsion/projectA/dev
>> /mydivsion/projectA/QA
>> /mydivsion/projectA/prod
>> /mydivsion/projectB/dev
>> /mydivsion/projectB/QA
>> /mydivsion/projectB/prod
>>
>> Obviously the idea of a project name (née tenant) being unique has
been around since near the beginning of (OpenStack) time, so we must be
cautions. There are two alternative specs proposed:
>>
>> 1) Relax project name constraints:
https://review.openstack.org/#/c/310048/
>> 2) Hierarchical project naming:
https://review.openstack.org/#/c/318605/
>>
>> First, here’s what they have in common:
>>
>> a) They both solve the above problem
>> b) They both allow an authorization scope to use a path rather than
just a simple name, hence allowing you to address a project anywhere in the
hierarchy
>> c) Neither have any impact if you are NOT using a hierarchy - i.e.
if you just have a flat layer of projects in a domain, then they have no
API or semantic impact (since both ensure that a project’s name must still
be unique within a parent)
>>
>> Here’s how the differ:
>>
>> - Relax project name constraints (1), keeps the meaning of the
‘name’ attribute of a project to be its node-name in the hierarchy, but
formally relaxes the uniqueness constraint to say that it only has to be
unique within its parent. In other words, let’s really model this a bit
like a unix directory tree.
>>>
>>> I think I lean towards relaxing the project name constraint. The reason
is because we already expose `domain_id`, `parent_id`, and `name` of a
project. By relaxing the constraint we can give the user everything the
need to know about a project without really changing any of these. When
using 3.7, you know what domain your project is in, you know the identifier
of the parent project, and you know that your project name is unique within
the parent.
>>
>> - Hierarchical project naming (2), formally changes the meaning of
the ‘name’ attribute to include the path to the node as well as the node
name, and hence ensures that the (new) value of the name attribute remains
unique.
>>>
>>> Do we intend to *store* the full path as the name, or just build it out
on demand? If we do store the full path, we will have to think about our
current data model since the depth of the organization or domain would be
limited by the max possible name length. Will performance be something to
think about building the full path on every request?
>>
>> I now mention this issue in the spec for hierarchical project naming
(the relax naming approach does not suffer this issue). As you say, we’ll
have to change the DB (today it is only 64 chars) if we do store the full
path . This is slightly problematic since the maximum depth of hierarchy is
controlled by a config option, and hence could be changed. We will
absolutely have be able to build the path on-the-fly in order to support
legacy drivers (who won’t be able to store more than 64 chars). We may need
to do some performance tests to ascertain if we can get away with building
the path on-the-fly in all cases and avoid changing the table.  One
additional point is that, of course, the API will return this path whenever
it returns a project - so clients will need to be aware of this increase in
size.
>
>
> These are all good points that continue to push me towards relaxing the
project naming constraint :)
>>
>>
>> While whichever approach we chose would only be included in a new
microversion (3.7) of the Identity API, although some relevant APIs can
remain unaffected for a client talking 3.6 to a Newton server, not all can
be. As pointed out be jamielennox, this is a data modelling problem - if a
Newton server has created multiple projects called “dev” in the hierarchy,
a 3.6 client trying to scope a token simply to “dev” cannot be answered
correctly (and it is proposed we would have to return an 

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

[Lance Bragstad]

On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash  wrote:

>
> On 3 Jun 2016, at 16:38, Lance Bragstad  wrote:
>
>
>
> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  wrote:
>
>>
>> On 3 Jun 2016, at 01:22, Adam Young  wrote:
>>
>> On 06/02/2016 07:22 PM, Henry Nash wrote:
>>
>> Hi
>>
>> As you know, I have been working on specs that change the way we handle
>> the uniqueness of project names in Newton. The goal of this is to better
>> support project hierarchies, which as they stand today are restrictive in
>> that all project names within a domain must be unique, irrespective of
>> where in the hierarchy that projects sits (unlike, say, the unix directory
>> structure where a node name only has to be unique within its parent). Such
>> a restriction is particularly problematic when enterprise start modelling
>> things like test, QA and production as branches of a project hierarchy,
>> e.g.:
>>
>> /mydivsion/projectA/dev
>> /mydivsion/projectA/QA
>> /mydivsion/projectA/prod
>> /mydivsion/projectB/dev
>> /mydivsion/projectB/QA
>> /mydivsion/projectB/prod
>>
>> Obviously the idea of a project name (née tenant) being unique has been
>> around since near the beginning of (OpenStack) time, so we must be
>> cautions. There are two alternative specs proposed:
>>
>> 1) Relax project name constraints:
>> 
>> https://review.openstack.org/#/c/310048/
>> 2) Hierarchical project naming:
>> 
>> https://review.openstack.org/#/c/318605/
>>
>> First, here’s what they have in common:
>>
>> a) They both solve the above problem
>> b) They both allow an authorization scope to use a path rather than just
>> a simple name, hence allowing you to address a project anywhere in the
>> hierarchy
>> c) Neither have any impact if you are NOT using a hierarchy - i.e. if you
>> just have a flat layer of projects in a domain, then they have no API or
>> semantic impact (since both ensure that a project’s name must still be
>> unique within a parent)
>>
>> Here’s how the differ:
>>
>> - Relax project name constraints (1), keeps the meaning of the ‘name’
>> attribute of a project to be its node-name in the hierarchy, but formally
>> relaxes the uniqueness constraint to say that it only has to be unique
>> within its parent. In other words, let’s really model this a bit like a
>> unix directory tree.
>>
>> I think I lean towards relaxing the project name constraint. The reason
> is because we already expose `domain_id`, `parent_id`, and `name` of a
> project. By relaxing the constraint we can give the user everything the
> need to know about a project without really changing any of these. When
> using 3.7, you know what domain your project is in, you know the identifier
> of the parent project, and you know that your project name is unique within
> the parent.
>
>> - Hierarchical project naming (2), formally changes the meaning of the
>> ‘name’ attribute to include the path to the node as well as the node name,
>> and hence ensures that the (new) value of the name attribute remains unique.
>>
>> Do we intend to *store* the full path as the name, or just build it out
> on demand? If we do store the full path, we will have to think about our
> current data model since the depth of the organization or domain would be
> limited by the max possible name length. Will performance be something to
> think about building the full path on every request?
>
> I now mention this issue in the spec for hierarchical project naming (the
> relax naming approach does not suffer this issue). As you say, we’ll have
> to change the DB (today it is only 64 chars) if we do store the full path .
> This is slightly problematic since the maximum depth of hierarchy is
> controlled by a config option, and hence could be changed. We will
> absolutely have be able to build the path on-the-fly in order to support
> legacy drivers (who won’t be able to store more than 64 chars). We may need
> to do some performance tests to ascertain if we can get away with building
> the path on-the-fly in all cases and avoid changing the table.  One
> additional point is that, of course, the API will return this path whenever
> it returns a project - so clients will need to be aware of this increase in
> size.
>

These are all good points that continue to push me towards relaxing the
project naming constraint :)

>
>> While whichever approach we chose would only be included in a new
>> microversion (3.7) of the Identity API, although some relevant APIs can
>> remain unaffected for a client talking 3.6 to a Newton server, not all can
>> be. As pointed out be jamielennox, this is a data modelling problem - if a
>> Newton server has created multiple projects called “dev” in the hierarchy,
>> a 3.6 client trying to scope a token simply to “dev” cannot be answered
>> correctly (and it is proposed we would have to return an HTTP 409 Conflict

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

[Henry Nash]

> On 3 Jun 2016, at 16:38, Lance Bragstad  wrote:
> 
> 
> 
> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  > wrote:
> 
>> On 3 Jun 2016, at 01:22, Adam Young > > wrote:
>> 
>> On 06/02/2016 07:22 PM, Henry Nash wrote:
>>> Hi
>>> 
>>> As you know, I have been working on specs that change the way we handle the 
>>> uniqueness of project names in Newton. The goal of this is to better 
>>> support project hierarchies, which as they stand today are restrictive in 
>>> that all project names within a domain must be unique, irrespective of 
>>> where in the hierarchy that projects sits (unlike, say, the unix directory 
>>> structure where a node name only has to be unique within its parent). Such 
>>> a restriction is particularly problematic when enterprise start modelling 
>>> things like test, QA and production as branches of a project hierarchy, 
>>> e.g.:
>>> 
>>> /mydivsion/projectA/dev
>>> /mydivsion/projectA/QA
>>> /mydivsion/projectA/prod
>>> /mydivsion/projectB/dev
>>> /mydivsion/projectB/QA
>>> /mydivsion/projectB/prod
>>> 
>>> Obviously the idea of a project name (née tenant) being unique has been 
>>> around since near the beginning of (OpenStack) time, so we must be 
>>> cautions. There are two alternative specs proposed:
>>> 
>>> 1) Relax project name constraints:  
>>> https://review.openstack.org/#/c/310048/
>>>   
>>> 2) Hierarchical project naming:  
>>> https://review.openstack.org/#/c/318605/
>>>  
>>> 
>>> First, here’s what they have in common:
>>> 
>>> a) They both solve the above problem
>>> b) They both allow an authorization scope to use a path rather than just a 
>>> simple name, hence allowing you to address a project anywhere in the 
>>> hierarchy
>>> c) Neither have any impact if you are NOT using a hierarchy - i.e. if you 
>>> just have a flat layer of projects in a domain, then they have no API or 
>>> semantic impact (since both ensure that a project’s name must still be 
>>> unique within a parent)
>>> 
>>> Here’s how the differ:
>>> 
>>> - Relax project name constraints (1), keeps the meaning of the ‘name’ 
>>> attribute of a project to be its node-name in the hierarchy, but formally 
>>> relaxes the uniqueness constraint to say that it only has to be unique 
>>> within its parent. In other words, let’s really model this a bit like a 
>>> unix directory tree.
> 
> I think I lean towards relaxing the project name constraint. The reason is 
> because we already expose `domain_id`, `parent_id`, and `name` of a project. 
> By relaxing the constraint we can give the user everything the need to know 
> about a project without really changing any of these. When using 3.7, you 
> know what domain your project is in, you know the identifier of the parent 
> project, and you know that your project name is unique within the parent.  
>>> - Hierarchical project naming (2), formally changes the meaning of the 
>>> ‘name’ attribute to include the path to the node as well as the node name, 
>>> and hence ensures that the (new) value of the name attribute remains unique.
> 
> Do we intend to *store* the full path as the name, or just build it out on 
> demand? If we do store the full path, we will have to think about our current 
> data model since the depth of the organization or domain would be limited by 
> the max possible name length. Will performance be something to think about 
> building the full path on every request?   
I now mention this issue in the spec for hierarchical project naming (the relax 
naming approach does not suffer this issue). As you say, we’ll have to change 
the DB (today it is only 64 chars) if we do store the full path . This is 
slightly problematic since the maximum depth of hierarchy is controlled by a 
config option, and hence could be changed. We will absolutely have be able to 
build the path on-the-fly in order to support legacy drivers (who won’t be able 
to store more than 64 chars). We may need to do some performance tests to 
ascertain if we can get away with building the path on-the-fly in all cases and 
avoid changing the table.  One additional point is that, of course, the API 
will return this path whenever it returns a project - so clients will need to 
be aware of this increase in size. 
>>> 
>>> While whichever approach we chose would only be included in a new 
>>> microversion (3.7) of the Identity API, although some relevant APIs can 
>>> remain unaffected for a client talking 3.6 to a Newton server, not all can 
>>> be. As pointed out be jamielennox, this is a data modelling problem - if a 
>>> Newton server has created multiple projects called “dev” in the hierarchy, 
>>> a 3.6 client trying to scope a token simply to “dev” cannot be answered 
>>> correctly (and 

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

[Lance Bragstad]

On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  wrote:

>
> On 3 Jun 2016, at 01:22, Adam Young  wrote:
>
> On 06/02/2016 07:22 PM, Henry Nash wrote:
>
> Hi
>
> As you know, I have been working on specs that change the way we handle
> the uniqueness of project names in Newton. The goal of this is to better
> support project hierarchies, which as they stand today are restrictive in
> that all project names within a domain must be unique, irrespective of
> where in the hierarchy that projects sits (unlike, say, the unix directory
> structure where a node name only has to be unique within its parent). Such
> a restriction is particularly problematic when enterprise start modelling
> things like test, QA and production as branches of a project hierarchy,
> e.g.:
>
> /mydivsion/projectA/dev
> /mydivsion/projectA/QA
> /mydivsion/projectA/prod
> /mydivsion/projectB/dev
> /mydivsion/projectB/QA
> /mydivsion/projectB/prod
>
> Obviously the idea of a project name (née tenant) being unique has been
> around since near the beginning of (OpenStack) time, so we must be
> cautions. There are two alternative specs proposed:
>
> 1) Relax project name constraints:
> 
> https://review.openstack.org/#/c/310048/
> 2) Hierarchical project naming:
> 
> https://review.openstack.org/#/c/318605/
>
> First, here’s what they have in common:
>
> a) They both solve the above problem
> b) They both allow an authorization scope to use a path rather than just a
> simple name, hence allowing you to address a project anywhere in the
> hierarchy
> c) Neither have any impact if you are NOT using a hierarchy - i.e. if you
> just have a flat layer of projects in a domain, then they have no API or
> semantic impact (since both ensure that a project’s name must still be
> unique within a parent)
>
> Here’s how the differ:
>
> - Relax project name constraints (1), keeps the meaning of the ‘name’
> attribute of a project to be its node-name in the hierarchy, but formally
> relaxes the uniqueness constraint to say that it only has to be unique
> within its parent. In other words, let’s really model this a bit like a
> unix directory tree.
>
> I think I lean towards relaxing the project name constraint. The reason is
because we already expose `domain_id`, `parent_id`, and `name` of a
project. By relaxing the constraint we can give the user everything the
need to know about a project without really changing any of these. When
using 3.7, you know what domain your project is in, you know the identifier
of the parent project, and you know that your project name is unique within
the parent.

> - Hierarchical project naming (2), formally changes the meaning of the
> ‘name’ attribute to include the path to the node as well as the node name,
> and hence ensures that the (new) value of the name attribute remains unique.
>
> Do we intend to *store* the full path as the name, or just build it out on
demand? If we do store the full path, we will have to think about our
current data model since the depth of the organization or domain would be
limited by the max possible name length. Will performance be something to
think about building the full path on every request?

>
> While whichever approach we chose would only be included in a new
> microversion (3.7) of the Identity API, although some relevant APIs can
> remain unaffected for a client talking 3.6 to a Newton server, not all can
> be. As pointed out be jamielennox, this is a data modelling problem - if a
> Newton server has created multiple projects called “dev” in the hierarchy,
> a 3.6 client trying to scope a token simply to “dev” cannot be answered
> correctly (and it is proposed we would have to return an HTTP 409 Conflict
> error if multiple nodes with the same name were detected). This is true for
> both approaches.
>
> Other comments on the approaches:
>
> - Having a full path as the name seems duplicative with the current
> project entity - since we already return the parent_id (hence parent_id +
> name is, today, sufficient to place a project in the hierarchy).
>
>
> The one thing I like is the ability to specify just the full path for the
> OS_PROJECT_NAME env var, but we could make that a separate variable.  Just
> as DOMAIN_ID + PROJECT_NAME is unique today, OS_PROJECT_PATH should be able
> to fully specify a project unambiguously.  I'm not sure which would have a
> larger impact on users.
>
> Agreed - and this could be done for both approaches (since this is all
> part of the “auth data flow").
>
>
> - In the past, we have been concerned about the issue of what we do if
> there is a project further up the tree that we do not have any roles on. In
> such cases, APIs like list project parents will not display anything other
> than the project ID for such projects. In the case of making the name the
> full path, we would be effectively exposing the name of all projects above
> 

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

[Henry Nash]

> On 3 Jun 2016, at 01:22, Adam Young  wrote:
> 
> On 06/02/2016 07:22 PM, Henry Nash wrote:
>> Hi
>> 
>> As you know, I have been working on specs that change the way we handle the 
>> uniqueness of project names in Newton. The goal of this is to better support 
>> project hierarchies, which as they stand today are restrictive in that all 
>> project names within a domain must be unique, irrespective of where in the 
>> hierarchy that projects sits (unlike, say, the unix directory structure 
>> where a node name only has to be unique within its parent). Such a 
>> restriction is particularly problematic when enterprise start modelling 
>> things like test, QA and production as branches of a project hierarchy, e.g.:
>> 
>> /mydivsion/projectA/dev
>> /mydivsion/projectA/QA
>> /mydivsion/projectA/prod
>> /mydivsion/projectB/dev
>> /mydivsion/projectB/QA
>> /mydivsion/projectB/prod
>> 
>> Obviously the idea of a project name (née tenant) being unique has been 
>> around since near the beginning of (OpenStack) time, so we must be cautions. 
>> There are two alternative specs proposed:
>> 
>> 1) Relax project name constraints:  
>> https://review.openstack.org/#/c/310048/
>>   
>> 2) Hierarchical project naming:  
>> https://review.openstack.org/#/c/318605/
>>  
>> 
>> First, here’s what they have in common:
>> 
>> a) They both solve the above problem
>> b) They both allow an authorization scope to use a path rather than just a 
>> simple name, hence allowing you to address a project anywhere in the 
>> hierarchy
>> c) Neither have any impact if you are NOT using a hierarchy - i.e. if you 
>> just have a flat layer of projects in a domain, then they have no API or 
>> semantic impact (since both ensure that a project’s name must still be 
>> unique within a parent)
>> 
>> Here’s how the differ:
>> 
>> - Relax project name constraints (1), keeps the meaning of the ‘name’ 
>> attribute of a project to be its node-name in the hierarchy, but formally 
>> relaxes the uniqueness constraint to say that it only has to be unique 
>> within its parent. In other words, let’s really model this a bit like a unix 
>> directory tree.
>> - Hierarchical project naming (2), formally changes the meaning of the 
>> ‘name’ attribute to include the path to the node as well as the node name, 
>> and hence ensures that the (new) value of the name attribute remains unique.
>> 
>> While whichever approach we chose would only be included in a new 
>> microversion (3.7) of the Identity API, although some relevant APIs can 
>> remain unaffected for a client talking 3.6 to a Newton server, not all can 
>> be. As pointed out be jamielennox, this is a data modelling problem - if a 
>> Newton server has created multiple projects called “dev” in the hierarchy, a 
>> 3.6 client trying to scope a token simply to “dev” cannot be answered 
>> correctly (and it is proposed we would have to return an HTTP 409 Conflict 
>> error if multiple nodes with the same name were detected). This is true for 
>> both approaches.
>> 
>> Other comments on the approaches:
>> 
>> - Having a full path as the name seems duplicative with the current project 
>> entity - since we already return the parent_id (hence parent_id + name is, 
>> today, sufficient to place a project in the hierarchy).
> 
> The one thing I like is the ability to specify just the full path for the 
> OS_PROJECT_NAME env var, but we could make that a separate variable.  Just as 
> DOMAIN_ID + PROJECT_NAME is unique today, OS_PROJECT_PATH should be able to 
> fully specify a project unambiguously.  I'm not sure which would have a 
> larger impact on users.
> 
Agreed - and this could be done for both approaches (since this is all part of 
the “auth data flow").
> 
>> - In the past, we have been concerned about the issue of what we do if there 
>> is a project further up the tree that we do not have any roles on. In such 
>> cases, APIs like list project parents will not display anything other than 
>> the project ID for such projects. In the case of making the name the full 
>> path, we would be effectively exposing the name of all projects above us, 
>> irrespective of whether we had roles on them. Maybe this is OK, maybe it 
>> isn’t.
> 
> I think it is OK.  If this info needs to be hidden from a user, the project 
> should probably be in a different domain.
> 
>> - While making the name the path keeps it unique, this is fine if clients 
>> blindly use this attribute to plug back into another API to call. However 
>> if, for example, you are Horizon and are displaying them in a UI then you 
>> need to start breaking down the path into its components, where you don’t 
>> today.
>> - One area where names as the hierarchical path DOES look right is calling 
>> the /auth/projects API - where what the caller wants 

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

[Adam Young]

On 06/02/2016 07:22 PM, Henry Nash wrote:

Hi

As you know, I have been working on specs that change the way we 
handle the uniqueness of project names in Newton. The goal of this is 
to better support project hierarchies, which as they stand today are 
restrictive in that all project names within a domain must be unique, 
irrespective of where in the hierarchy that projects sits (unlike, 
say, the unix directory structure where a node name only has to be 
unique within its parent). Such a restriction is particularly 
problematic when enterprise start modelling things like test, QA and 
production as branches of a project hierarchy, e.g.:


/mydivsion/projectA/dev
/mydivsion/projectA/QA
/mydivsion/projectA/prod
/mydivsion/projectB/dev
/mydivsion/projectB/QA
/mydivsion/projectB/prod

Obviously the idea of a project name (née tenant) being unique has 
been around since near the beginning of (OpenStack) time, so we must 
be cautions. There are two alternative specs proposed:


1) Relax project name constraints: 
https://review.openstack.org/#/c/310048/

2) Hierarchical project naming: https://review.openstack.org/#/c/318605/

First, here’s what they have in common:

a) They both solve the above problem
b) They both allow an authorization scope to use a path rather than 
just a simple name, hence allowing you to address a project anywhere 
in the hierarchy
c) Neither have any impact if you are NOT using a hierarchy - i.e. if 
you just have a flat layer of projects in a domain, then they have no 
API or semantic impact (since both ensure that a project’s name must 
still be unique within a parent)


Here’s how the differ:

- Relax project name constraints (1), keeps the meaning of the ‘name’ 
attribute of a project to be its node-name in the hierarchy, but 
formally relaxes the uniqueness constraint to say that it only has to 
be unique within its parent. In other words, let’s really model this a 
bit like a unix directory tree.
- Hierarchical project naming (2), formally changes the meaning of the 
‘name’ attribute to include the path to the node as well as the node 
name, and hence ensures that the (new) value of the name attribute 
remains unique.


While whichever approach we chose would only be included in a new 
microversion (3.7) of the Identity API, although some relevant APIs 
can remain unaffected for a client talking 3.6 to a Newton server, not 
all can be. As pointed out be jamielennox, this is a data modelling 
problem - if a Newton server has created multiple projects called 
“dev” in the hierarchy, a 3.6 client trying to scope a token simply to 
“dev” cannot be answered correctly (and it is proposed we would have 
to return an HTTP 409 Conflict error if multiple nodes with the same 
name were detected). This is true for both approaches.


Other comments on the approaches:

- Having a full path as the name seems duplicative with the current 
project entity - since we already return the parent_id (hence 
parent_id + name is, today, sufficient to place a project in the 
hierarchy).


The one thing I like is the ability to specify just the full path for 
the OS_PROJECT_NAME env var, but we could make that a separate 
variable.  Just as DOMAIN_ID + PROJECT_NAME is unique today, 
OS_PROJECT_PATH should be able to fully specify a project 
unambiguously.  I'm not sure which would have a larger impact on users.



- In the past, we have been concerned about the issue of what we do if 
there is a project further up the tree that we do not have any roles 
on. In such cases, APIs like list project parents will not display 
anything other than the project ID for such projects. In the case of 
making the name the full path, we would be effectively exposing the 
name of all projects above us, irrespective of whether we had roles on 
them. Maybe this is OK, maybe it isn’t.


I think it is OK.  If this info needs to be hidden from a user, the 
project should probably be in a different domain.


- While making the name the path keeps it unique, this is fine if 
clients blindly use this attribute to plug back into another API to 
call. However if, for example, you are Horizon and are displaying them 
in a UI then you need to start breaking down the path into its 
components, where you don’t today.
- One area where names as the hierarchical path DOES look right is 
calling the /auth/projects API - where what the caller wants is a list 
of projects they can scope to - so you WANT this to be the path you 
can put in an auth request.


Given that neither can fully protect a 3.6 client, my personal 
preference is to go with the cleaner logical approach which I believe 
is the Relax project name constraints (1), with the addition of 
changing GET /auth/projects to return the path (since this is a 
specialised API that happens before authentication) - but I am open to 
persuasion (as the song goes).


There are those that might say that perhaps we just can’t change this. 
I would argue that since this ONLY affects 

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

[Henry Nash]

Hi

As you know, I have been working on specs that change the way we handle the 
uniqueness of project names in Newton. The goal of this is to better support 
project hierarchies, which as they stand today are restrictive in that all 
project names within a domain must be unique, irrespective of where in the 
hierarchy that projects sits (unlike, say, the unix directory structure where a 
node name only has to be unique within its parent). Such a restriction is 
particularly problematic when enterprise start modelling things like test, QA 
and production as branches of a project hierarchy, e.g.:

/mydivsion/projectA/dev
/mydivsion/projectA/QA
/mydivsion/projectA/prod
/mydivsion/projectB/dev
/mydivsion/projectB/QA
/mydivsion/projectB/prod

Obviously the idea of a project name (née tenant) being unique has been around 
since near the beginning of (OpenStack) time, so we must be cautions. There are 
two alternative specs proposed:

1) Relax project name constraints: https://review.openstack.org/#/c/310048/ 
 
2) Hierarchical project naming: https://review.openstack.org/#/c/318605/ 


First, here’s what they have in common:

a) They both solve the above problem
b) They both allow an authorization scope to use a path rather than just a 
simple name, hence allowing you to address a project anywhere in the hierarchy
c) Neither have any impact if you are NOT using a hierarchy - i.e. if you just 
have a flat layer of projects in a domain, then they have no API or semantic 
impact (since both ensure that a project’s name must still be unique within a 
parent)

Here’s how the differ:

- Relax project name constraints (1), keeps the meaning of the ‘name’ attribute 
of a project to be its node-name in the hierarchy, but formally relaxes the 
uniqueness constraint to say that it only has to be unique within its parent. 
In other words, let’s really model this a bit like a unix directory tree.
- Hierarchical project naming (2), formally changes the meaning of the ‘name’ 
attribute to include the path to the node as well as the node name, and hence 
ensures that the (new) value of the name attribute remains unique.

While whichever approach we chose would only be included in a new microversion 
(3.7) of the Identity API, although some relevant APIs can remain unaffected 
for a client talking 3.6 to a Newton server, not all can be. As pointed out be 
jamielennox, this is a data modelling problem - if a Newton server has created 
multiple projects called “dev” in the hierarchy, a 3.6 client trying to scope a 
token simply to “dev” cannot be answered correctly (and it is proposed we would 
have to return an HTTP 409 Conflict error if multiple nodes with the same name 
were detected). This is true for both approaches.

Other comments on the approaches:

- Having a full path as the name seems duplicative with the current project 
entity - since we already return the parent_id (hence parent_id + name is, 
today, sufficient to place a project in the hierarchy).
- In the past, we have been concerned about the issue of what we do if there is 
a project further up the tree that we do not have any roles on. In such cases, 
APIs like list project parents will not display anything other than the project 
ID for such projects. In the case of making the name the full path, we would be 
effectively exposing the name of all projects above us, irrespective of whether 
we had roles on them. Maybe this is OK, maybe it isn’t.
- While making the name the path keeps it unique, this is fine if clients 
blindly use this attribute to plug back into another API to call. However if, 
for example, you are Horizon and are displaying them in a UI then you need to 
start breaking down the path into its components, where you don’t today.
- One area where names as the hierarchical path DOES look right is calling the 
/auth/projects API - where what the caller wants is a list of projects they can 
scope to - so you WANT this to be the path you can put in an auth request.

Given that neither can fully protect a 3.6 client, my personal preference is to 
go with the cleaner logical approach which I believe is the Relax project name 
constraints (1), with the addition of changing GET /auth/projects to return the 
path (since this is a specialised API that happens before authentication) - but 
I am open to persuasion (as the song goes).

There are those that might say that perhaps we just can’t change this. I would 
argue that since this ONLY affects people who actually create hierarchies and 
that today such hierarchical use is in its infancy, then now IS the time to 
change this. If we leave it too long, then it will become really hard to change 
what will by then have become a tough restriction.

Henry


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: