<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="">I am sure I have missed something along the way, but can someone explain to me why we need this at all. Project names are unique within a domain, with the exception of the project that is acting as its domain (i.e. they can only every be two names clashing in a hierarchy at the domain level and below). So why isn’t specifying “is_domain=True/False” sufficient in an auth scope along with the project name?<div class=""><br class=""></div><div class="">Henry</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 5 Jun 2015, at 18:02, 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/03/2015 05:05 PM, Morgan Fainberg
wrote:<br class="">
</div>
<blockquote cite="mid:CAGnj6auFodRKREcTniEvfosXYAYEmkPSn0stoGfKy9wRB4M6bA@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">Hi David,
<div class=""><br class="">
</div>
<div class="">There needs to be some form of global hierarchy delimiter -
well more to the point there should be a common one across
OpenStack installations to ensure we are providing a good and
consistent (and more to the point inter-operable) experience
to our users. I'm worried a custom defined delimiter (even at
the domain level) is going to make it difficult to consume
this data outside of the context of OpenStack (there are
applications that are written to use the APIs directly).</div>
</div>
</blockquote>
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.<br class="">
<br class="">
Nothing else is backwards compatible. Nothing else will ensure we
don;t break exisiting deployments.<br class="">
<br class="">
Moving forward, we should support DNS notation, but it has to be an
opt in<br class="">
<br class="">
<blockquote cite="mid:CAGnj6auFodRKREcTniEvfosXYAYEmkPSn0stoGfKy9wRB4M6bA@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">The alternative is to explicitly list the delimiter in the
project ( e.g. <font face="monospace, monospace" class="">{"hierarchy":
{"delim": ".", "domain.project.project2"}}</font><font face="arial, helvetica, sans-serif" class=""> ). The additional need
to look up the delimiter / set the delimiter when creating a
domain is likely to make for a worse user experience than
selecting one that is not different across installations.</font><br class="">
</div>
<div class=""><font face="arial, helvetica, sans-serif" class=""><br class="">
</font></div>
<div class=""><font face="arial, helvetica, sans-serif" class="">--Morgan</font></div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Jun 3, 2015 at 12:19 PM, David
Chadwick <span dir="ltr" class=""><<a moz-do-not-send="true" href="mailto:d.w.chadwick@kent.ac.uk" target="_blank" class="">d.w.chadwick@kent.ac.uk</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
<br class="">
On 03/06/2015 14:54, Henrique Truta wrote:<br class="">
> Hi David,<br class="">
><br class="">
> You mean creating some kind of "delimiter" attribute
in the domain<br class="">
> entity? That seems like a good idea, although it does
not solve the<br class="">
> problem Morgan's mentioned that is the global
hierarchy delimiter.<br class="">
<br class="">
</span>There would be no global hierarchy delimiter. Each
domain would define<br class="">
its own and this would be carried in the JSON as a separate
parameter so<br class="">
that the recipient can tell how to parse hierarchical names<br class="">
<br class="">
David<br class="">
<span class=""><br class="">
><br class="">
> Henrique<br class="">
><br class="">
> Em qua, 3 de jun de 2015 às 04:21, David Chadwick<br class="">
</span>> <<a moz-do-not-send="true" href="mailto:d.w.chadwick@kent.ac.uk" class="">d.w.chadwick@kent.ac.uk</a>
<mailto:<a moz-do-not-send="true" href="mailto:d.w.chadwick@kent.ac.uk" class="">d.w.chadwick@kent.ac.uk</a>>>
escreveu:<br class="">
<div class="">
<div class="h5">><br class="">
><br class="">
><br class="">
> On 02/06/2015 23:34, Morgan Fainberg wrote:<br class="">
> > Hi Henrique,<br class="">
> ><br class="">
> > I don't think we need to specifically call
out that we want a<br class="">
> domain, we<br class="">
> > should always reference the namespace as
we do today. Basically, if we<br class="">
> > ask for a project name we need to also
provide it's namespace (your<br class="">
> > option #1). This clearly lines up with how
we handle projects in<br class="">
> domains<br class="">
> > today.<br class="">
> ><br class="">
> > I would, however, focus on how to
represent the namespace in a single<br class="">
> > (usable) string. We've been delaying the
work on this for a while<br class="">
> since<br class="">
> > we have historically not provided a clear
way to delimit the<br class="">
> hierarchy.<br class="">
> > If we solve the issue with "what is the
delimiter" between domain,<br class="">
> > project, and subdomain/subproject, we end
up solving the usability<br class="">
><br class="">
> why not allow the top level domain/project to
define the delimiter for<br class="">
> its tree, and to carry the delimiter in the
JSON as a new parameter.<br class="">
> That provides full flexibility for all
languages and locales<br class="">
><br class="">
> David<br class="">
><br class="">
> > issues with proposal #1, and not breaking
the current behavior you'd<br class="">
> > expect with implementing option #2 (which
at face value feels to<br class="">
> be API<br class="">
> > incompatible/break of current behavior).<br class="">
> ><br class="">
> > Cheers,<br class="">
> > --Morgan<br class="">
> ><br class="">
> > On Tue, Jun 2, 2015 at 7:43 AM, Henrique
Truta<br class="">
> > <<a moz-do-not-send="true" href="mailto:henriquecostatruta@gmail.com" class="">henriquecostatruta@gmail.com</a><br class="">
> <mailto:<a moz-do-not-send="true" href="mailto:henriquecostatruta@gmail.com" class="">henriquecostatruta@gmail.com</a>><br class="">
</div>
</div>
> <mailto:<a moz-do-not-send="true" href="mailto:henriquecostatruta@gmail.com" class="">henriquecostatruta@gmail.com</a><br class="">
<div class="HOEnZb">
<div class="h5">> <mailto:<a moz-do-not-send="true" href="mailto:henriquecostatruta@gmail.com" class="">henriquecostatruta@gmail.com</a>>>>
wrote:<br class="">
> ><br class="">
> > Hi folks,<br class="">
> ><br class="">
> ><br class="">
> > In Reseller[1], we’ll have the domains
concept merged into<br class="">
> projects,<br class="">
> > that means that we will have projects
that will behave as domains.<br class="">
> > Therefore, it will be possible to have
two projects with the same<br class="">
> > name in a hierarchy, one being a
domain and another being a<br class="">
> regular<br class="">
> > project. For instance, the following
hierarchy will be valid:<br class="">
> ><br class="">
> > A - is_domain project, with domain A<br class="">
> ><br class="">
> > |<br class="">
> ><br class="">
> > B - project<br class="">
> ><br class="">
> > |<br class="">
> ><br class="">
> > A - project with domain A<br class="">
> ><br class="">
> ><br class="">
> > That hierarchy faces a problem when a
user requests a project<br class="">
> scoped<br class="">
> > token by name, once she’ll pass
“domain = ‘A’” and<br class="">
> <a moz-do-not-send="true" href="http://project.name/" target="_blank" class="">project.name</a>
<<a moz-do-not-send="true" href="http://project.name/" target="_blank" class="">http://project.name</a>><br class="">
> > <<a moz-do-not-send="true" href="http://project.name/" target="_blank" class="">http://project.name</a>>
= “A”. Currently, we have no way to<br class="">
> > distinguish which project we are
referring to. We have two<br class="">
> proposals<br class="">
> > for this.<br class="">
> ><br class="">
> ><br class="">
> > 1.<br class="">
> ><br class="">
> > Specify the whole hierarchy in the
token request body, which<br class="">
> > means that when requesting a token
for the child project for<br class="">
> > that hierarchy, we’ll have in the
scope field something like:<br class="">
> ><br class="">
> > "project": {<br class="">
> > "domain": {<br class="">
> > "name": "A"<br class="">
> > },<br class="">
> > "name": [“A”', “B”,
“A”]<br class="">
> > }<br class="">
> ><br class="">
> ><br class="">
> > If the project name is unique inside
the domain (project “B”, for<br class="">
> > example), the hierarchy is optional.<br class="">
> ><br class="">
> ><br class="">
> > 2.<br class="">
> ><br class="">
> > When a conflict happen, always
provide a token to the child<br class="">
> > project. That means that, in case
we have a name clashing as<br class="">
> > described, it will only be
possible to get a project scoped<br class="">
> > token to the is_domain project
through its id.<br class="">
> ><br class="">
> ><br class="">
> ><br class="">
> > The former will give us more clarity
and won’t create any more<br class="">
> > restrictions than we already have. As
a con, we currently are not<br class="">
> > able to get the names of projects in
the hierarchy above a given<br class="">
> > project. Although the latter seems to
hurt fewer people, it<br class="">
> has the<br class="">
> > disadvantage of creating another set
of constraints that might<br class="">
> > difficult the UX in the future.<br class="">
> ><br class="">
> ><br class="">
> > What do you think about that? We want
to hear your oppinion, so we<br class="">
> > can discuss it at today’s Keystone
Meeting.<br class="">
> ><br class="">
> ><br class="">
> > [1]<br class="">
> ><br class="">
> <a moz-do-not-send="true" href="https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst" target="_blank" class="">https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst</a><br class="">
> ><br class="">
> ><br class="">
> ><br class="">
>
__________________________________________________________________________<br class="">
> > OpenStack Development Mailing List
(not for usage questions)<br class="">
> > Unsubscribe:<br class="">
> > <a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
> <<a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br class="">
> ><br class="">
> <<a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br class="">
> > <a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
> ><br class="">
> ><br class="">
> ><br class="">
> ><br class="">
> ><br class="">
>
__________________________________________________________________________<br class="">
> > OpenStack Development Mailing List (not
for usage questions)<br class="">
> > Unsubscribe:<br class="">
> <a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
> <<a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br class="">
> > <a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
> ><br class="">
><br class="">
>
__________________________________________________________________________<br class="">
> OpenStack Development Mailing List (not for
usage questions)<br class="">
> Unsubscribe:<br class="">
> <a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
> <<a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br class="">
> <a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
><br class="">
><br class="">
><br class="">
>
__________________________________________________________________________<br class="">
> OpenStack Development Mailing List (not for usage
questions)<br class="">
> Unsubscribe: <a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
> <a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
><br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage
questions)<br class="">
Unsubscribe: <a moz-do-not-send="true" href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</div>
</div>
</blockquote>
</div>
<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>
<br class="">
</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>