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.
- 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
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.
- 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://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