On 06/04/2016 01:53 AM, Morgan Fainberg wrote: > > On Jun 3, 2016 12:42, "Lance Bragstad" <lbrags...@gmail.com > <mailto:lbrags...@gmail.com>> wrote: >> >> >> >> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash <henryna...@mac.com > <mailto:henryna...@mac.com>> wrote: >>> >>> >>>> On 3 Jun 2016, at 16:38, Lance Bragstad <lbrags...@gmail.com > <mailto:lbrags...@gmail.com>> wrote: >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <henryna...@mac.com > <mailto:henryna...@mac.com>> wrote: >>>>> >>>>> >>>>>> On 3 Jun 2016, at 01:22, Adam Young <ayo...@redhat.com > <mailto: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/ >>>>>>> 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 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 > <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://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://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > My main concern with relaxing the uniqueness is you now have a > significant issue with auth changing. Fundamentally you cannot scope to > a project under a domain by name and domain name alone. This will break > current auth paths and auth mechanisms. > > I personally think we are a bit wedged even with microversions without > providing the full path as a name for projects created as such (and > current projects retaining the uniqueness or if created via the old api > maintaining the uniqueness constraint and new api projects not being > represented at all). > > So in short, I am strongly against relaxing uniqueness.
I agree. This would break code that exists currently. A microversion is fine for creating a new api call. A microversion is not ok for fundamentally breaking the semantics of an existing API. This would be a major API version bump. It would break existing users with existing code, and since there _is_ another option on the table that does not break existing users with existing code, I believe that it is imperative to select the non-breaking option. > New (microversion) would make projects that are only represented by full > path. Old projects could be represented either way. (For auth/crud that > uses project names). > > Old microversion api (today) would require uniqueness constraint and not > show/allow full pathname projects. > > This way we do not break auth that works today. > > Most everyone consumes and stores by id (nova, cinder, etc) so we likely > won't break much with extended project names. End users work by name - but yes, I agree the impact cross-openstack is unlikely. __________________________________________________________________________ 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