[openstack-dev] [keystone] Changing the project name uniqueness constraint
ayoung at redhat.com
Fri Jun 3 00:22:45 UTC 2016
On 06/02/2016 07:22 PM, Henry Nash wrote:
> 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.:
> 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:
> 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.
> - 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.
> 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
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.
> - 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev