Open Stack

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 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160602/af0fa472/attachment.html>