On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash <henryna...@mac.com> wrote:
> > On 3 Jun 2016, at 16:38, Lance Bragstad <lbrags...@gmail.com> wrote: > > > > On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <henryna...@mac.com> wrote: > >> >> 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/ >> 2) Hierarchical project naming: >> <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. >> >> 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 >> 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:unsubscribehttp://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://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 > > > > __________________________________________________________________________ > 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