On further reflection, it seems to me that we can never simply enable either of these approaches in a single release. Even a v4.0 version of the API doesn’t help - since presumably a sever supporting v4 would want to be able to support v3.x for a signification time; and, already discussed, as soon as you allow multiple none-names to have the same name, you can no longer guarantee to support the current API.
Hence the only thing I think we can do (if we really do want to change the current functionality) is to do this over several releases with a typical deprecation cycle, e.g. 1) At release 3.7 we allow you to (optionally) specify path names for auth….but make no changes to the uniqueness constraints. We also change the GET /auth/projects to return a path name. However, you can still auth exactly the way we do today (since there will always only be a single project of a given node-name). If however, you do auth without a path (to a project that isn’t a top level project), we log a warning to say this is deprecated (2 cycles, 4 cycles?) 2) If you connect with a 3.6 client, then you get the same as today for GET /auth/projects and cannot use a path name to auth. 3) At sometime in the future, we deprecate the “auth without a path” capability. We can debate as to whether this has to be a major release. If we take this gradual approach, I would be pushing for the “relax project name constraints” approach…since I believe this leads to a cleaner eventual solution (and there is no particular advantage with the hierarchical naming approach) - and (until the end of the deprecation) there is no break to the existing API. Henry > On 7 Jun 2016, at 09:47, Henry Nash <[email protected]> wrote: > > OK, so thanks for the feedback - understand the message. > > However, in terms of compatibility, the one thing that concerns me about the > hierarchical naming approach is that even with microversioing, we might still > surprise a client. An unmodified client (i.e. doesn’t understand 3.7) would > still see a change in the data being returned (the project names have > suddenly become full path names). We have to return this even if they don’t > ask for 3.7, since otherwise there is no difference between this approach and > relaxing the project naming in terms of trying to prevent auth breakages. > > In more detail: > > 1) Both approaches were planned to return the path name (instead of the node > name) in GET /auth/projects - i.e. the API you are meant to use to find out > what you can scope to > 2) Both approaches were planned to accept the path name in the auth request > block > 3) The difference in hierarchical naming is the if I do a regular GET > /project(s) I also see the full path name as the “project name” > > if we don’t do 3), then code that somehow authenticates, and then uses the > regular GET /project(s) calls to find a project name and then re-scopes (or > re-auths) to that name, will fail if the project they want is not a top level > project. However, the flip side is that if there is code that uses these same > calls to, say, display projects to the user (e.g. a home grown UI) - then it > might get confused until it supports 3.7 (i.e. asking for the old > microversion won’t help it) since all the names include the hierarchical path. > > Just want to make sure we understand the implications…. > > Henry > >> On 4 Jun 2016, at 08:34, Monty Taylor <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 06/04/2016 01:53 AM, Morgan Fainberg wrote: >>> >>> On Jun 3, 2016 12:42, "Lance Bragstad" <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>> >>>> >>>> >>>> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash <[email protected] >>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>>> >>>>> >>>>>> On 3 Jun 2016, at 16:38, Lance Bragstad <[email protected] >>>>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <[email protected] >>>>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>>>>> >>>>>>> >>>>>>>> On 3 Jun 2016, at 01:22, Adam Young <[email protected] >>>>>>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> 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: >>> [email protected] >>> <mailto:[email protected]>?subject:unsubscribe >>> <http://[email protected]?subject:unsubscribe >>> <http://[email protected]/?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: [email protected] >>> <mailto:[email protected]>?subject:unsubscribe >>> <http://[email protected]?subject:unsubscribe >>> <http://[email protected]/?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: [email protected] >>> <mailto:[email protected]>?subject:unsubscribe >>> <http://[email protected]?subject:unsubscribe >>> <http://[email protected]/?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: [email protected] >>> <mailto:[email protected]>?subject:unsubscribe >>> <http://[email protected]?subject:unsubscribe >>> <http://[email protected]/?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: >>> [email protected] >>> <mailto:[email protected]>?subject:unsubscribe >>> <http://[email protected]?subject:unsubscribe >>> <http://[email protected]/?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: >>> [email protected] >>> <mailto:[email protected]>?subject:unsubscribe >>> <http://[email protected]?subject:unsubscribe >>> <http://[email protected]/?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. >> >> 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: [email protected] >> <mailto:[email protected]>?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
