> On 3 Jun 2016, at 01:22, Adam Young <ayo...@redhat.com> 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/>https://review.openstack.org/#/c/310048/ >> <https://review.openstack.org/#/c/310048/> >> 2) Hierarchical project naming: >> <https://review.openstack.org/#/c/318605/>https://review.openstack.org/#/c/318605/ >> <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 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-requ...@lists.openstack.org?subject:unsubscribe >> <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > __________________________________________________________________________ > 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
__________________________________________________________________________ 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
