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 <morgan.fainb...@gmail.com> 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/ > >>>>>> <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:unsubscribe > >>>>>> <http://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://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://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://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://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://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> > > > > 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. > > 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. > > __________________________________________________________________________ > 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
