<div dir="ltr"><div><div><div>Hi David,<br><br></div>You mean creating some kind of "delimiter" attribute in the domain entity? That seems like a good idea, although it does not solve the problem Morgan's mentioned that is the global hierarchy delimiter.<br><br></div></div>Henrique<br></div><br><div class="gmail_quote"><div dir="ltr">Em qua, 3 de jun de 2015 às 04:21, David Chadwick <<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 02/06/2015 23:34, Morgan Fainberg wrote:<br>
> Hi Henrique,<br>
><br>
> I don't think we need to specifically call out that we want a domain, we<br>
> should always reference the namespace as we do today. Basically, if we<br>
> ask for a project name we need to also provide it's namespace (your<br>
> option #1). This clearly lines up with how we handle projects in domains<br>
> today.<br>
><br>
> I would, however, focus on how to represent the namespace in a single<br>
> (usable) string. We've been delaying the work on this for a while since<br>
> we have historically not provided a clear way to delimit the hierarchy.<br>
> If we solve the issue with "what is the delimiter" between domain,<br>
> project, and subdomain/subproject, we end up solving the usability<br>
<br>
why not allow the top level domain/project to define the delimiter for<br>
its tree, and to carry the delimiter in the JSON as a new parameter.<br>
That provides full flexibility for all languages and locales<br>
<br>
David<br>
<br>
> issues with proposal #1, and not breaking the current behavior you'd<br>
> expect with implementing option #2 (which at face value feels to be API<br>
> incompatible/break of current behavior).<br>
><br>
> Cheers,<br>
> --Morgan<br>
><br>
> On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta<br>
> <<a href="mailto:henriquecostatruta@gmail.com" target="_blank">henriquecostatruta@gmail.com</a> <mailto:<a href="mailto:henriquecostatruta@gmail.com" target="_blank">henriquecostatruta@gmail.com</a>>> wrote:<br>
><br>
> Hi folks,<br>
><br>
><br>
> In Reseller[1], we’ll have the domains concept merged into projects,<br>
> that means that we will have projects that will behave as domains.<br>
> Therefore, it will be possible to have two projects with the same<br>
> name in a hierarchy, one being a domain and another being a regular<br>
> project. For instance, the following hierarchy will be valid:<br>
><br>
> A - is_domain project, with domain A<br>
><br>
> |<br>
><br>
> B - project<br>
><br>
> |<br>
><br>
> A - project with domain A<br>
><br>
><br>
> That hierarchy faces a problem when a user requests a project scoped<br>
> token by name, once she’ll pass “domain = ‘A’” and <a href="http://project.name" target="_blank">project.name</a><br>
> <<a href="http://project.name" target="_blank">http://project.name</a>> = “A”. Currently, we have no way to<br>
> distinguish which project we are referring to. We have two proposals<br>
> for this.<br>
><br>
><br>
> 1.<br>
><br>
> Specify the whole hierarchy in the token request body, which<br>
> means that when requesting a token for the child project for<br>
> that hierarchy, we’ll have in the scope field something like:<br>
><br>
> "project": {<br>
> "domain": {<br>
> "name": "A"<br>
> },<br>
> "name": [“A”', “B”, “A”]<br>
> }<br>
><br>
><br>
> If the project name is unique inside the domain (project “B”, for<br>
> example), the hierarchy is optional.<br>
><br>
><br>
> 2.<br>
><br>
> When a conflict happen, always provide a token to the child<br>
> project. That means that, in case we have a name clashing as<br>
> described, it will only be possible to get a project scoped<br>
> token to the is_domain project through its id.<br>
><br>
><br>
><br>
> The former will give us more clarity and won’t create any more<br>
> restrictions than we already have. As a con, we currently are not<br>
> able to get the names of projects in the hierarchy above a given<br>
> project. Although the latter seems to hurt fewer people, it has the<br>
> disadvantage of creating another set of constraints that might<br>
> difficult the UX in the future.<br>
><br>
><br>
> What do you think about that? We want to hear your oppinion, so we<br>
> can discuss it at today’s Keystone Meeting.<br>
><br>
><br>
> [1]<br>
> <a href="https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst" target="_blank">https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst</a><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>