[openstack-dev] [keystone] Changing the project name uniqueness constraint

Lance Bragstad lbragstad at gmail.com
Fri Jun 3 19:42:22 UTC 2016


On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash <henrynash9 at mac.com> wrote:

>
> On 3 Jun 2016, at 16:38, Lance Bragstad <lbragstad at gmail.com> wrote:
>
>
>
> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <henrynash9 at mac.com> wrote:
>
>>
>> On 3 Jun 2016, at 01:22, Adam Young <ayoung at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160603/87582242/attachment.html>


More information about the OpenStack-dev mailing list