<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/05/2015 01:15 PM, Henry Nash
wrote:<br>
</div>
<blockquote cite="mid:95817A00-78E4-4C47-BD6F-73947941262E@mac.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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?</blockquote>
<br>
The limitation of " Project names are unique within a domain" is
artificial and somethi8ng we should not be enforcing. Names should
only be unique within parent project.<br>
<br>
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can
special case that, but it is not a great solution.<br>
<br>
<br>
<br>
<blockquote cite="mid:95817A00-78E4-4C47-BD6F-73947941262E@mac.com"
type="cite">
<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
moz-do-not-send="true" 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 class=""
face="monospace, monospace">{"hierarchy":
{"delim": ".", "domain.project.project2"}}</font><font
class="" face="arial, helvetica, sans-serif"> ).
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 class="" face="arial, helvetica,
sans-serif"><br class="">
</font></div>
<div class=""><font class="" face="arial, helvetica,
sans-serif">--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 class="" wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:OpenStack-dev-request@lists.openstack.org"
class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br
class="">
<a moz-do-not-send="true"
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="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
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>
</body>
</html>