<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Jun 2016, at 01:22, Adam Young <<a href="mailto:ayoung@redhat.com" class="">ayoung@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">On 06/02/2016 07:22 PM, Henry Nash
wrote:<br class="">
</div>
<blockquote cite="mid:B8017048-B837-4B40-A9CD-B4ED826530A5@mac.com" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
Hi
<div class=""><br class="">
</div>
<div class="">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.:</div>
<div class=""><br class="">
</div>
<div class="">/mydivsion/projectA/dev</div>
<div class="">/mydivsion/projectA/QA</div>
<div class="">/mydivsion/projectA/prod</div>
<div class="">
<div class="">/mydivsion/projectB/dev</div>
<div class="">/mydivsion/projectB/QA</div>
<div class="">/mydivsion/projectB/prod</div>
</div>
<div class=""><br class="">
</div>
<div class="">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:</div>
<div class=""><br class="">
</div>
<div class="">1) Relax project name constraints: <a moz-do-not-send="true" href="https://review.openstack.org/#/c/310048/" class=""></a><a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/310048/">https://review.openstack.org/#/c/310048/</a> </div>
<div class="">2) Hierarchical project naming: <a moz-do-not-send="true" href="https://review.openstack.org/#/c/318605/" class=""></a><a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/318605/">https://review.openstack.org/#/c/318605/</a></div>
<div class=""><br class="">
</div>
<div class="">First, here’s what they have in common:</div>
<div class=""><br class="">
</div>
<div class="">a) They both solve the above problem</div>
<div class="">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</div>
<div class="">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)</div>
<div class=""><br class="">
</div>
<div class="">Here’s how the differ:</div>
<div class=""><br class="">
</div>
<div class="">- 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.</div>
<div class="">- 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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Other comments on the approaches:</div>
<div class=""><br class="">
</div>
<div class="">- 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).</div>
</blockquote>
<br class="">
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.<br class="">
<br class=""></div></div></blockquote>Agreed - and this could be done for both approaches (since this is all part of the “auth data flow").<br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
<blockquote cite="mid:B8017048-B837-4B40-A9CD-B4ED826530A5@mac.com" type="cite" class="">
<div class="">- 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.</div>
</blockquote>
<br class="">
I think it is OK. If this info needs to be hidden from a user, the
project should probably be in a different domain.<br class="">
<br class="">
<blockquote cite="mid:B8017048-B837-4B40-A9CD-B4ED826530A5@mac.com" type="cite" class="">
<div class="">- 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.</div>
<div class="">- 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.</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Henry</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote><p class=""><br class="">
</p>
</div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></body></html>