<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
----- Original Message -----<br>
> From: "David Chadwick" <<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>><br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Sent: Saturday, 6 June, 2015 6:01:10 PM<br>
> Subject: Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name<br>
><br>
><br>
><br>
> On 06/06/2015 00:24, Adam Young wrote:<br>
> > On 06/05/2015 01:15 PM, Henry Nash wrote:<br>
> >> I am sure I have missed something along the way, but can someone<br>
> >> explain to me why we need this at all. Project names are unique<br>
> >> within a domain, with the exception of the project that is acting as<br>
> >> its domain (i.e. they can only every be two names clashing in a<br>
> >> hierarchy at the domain level and below). So why isn’t specifying<br>
> >> “is_domain=True/False” sufficient in an auth scope along with the<br>
> >> project name?<br>
> ><br>
> > The limitation of " Project names are unique within a domain" is<br>
> > artificial and somethi8ng we should not be enforcing. Names should only<br>
> > be unique within parent project.<br>
><br>
> +++1<br>
<br>
</span>I said the exact same thing as Henry in the other thread that seems to be on the same topic. You're correct the limitation of "Project names are unique within a domain" is completely artificial, but it's a constraint that allows us to maintain the auth systems we currently have and will not harm the reseller model (because they would be creating new domains).<br>
<br>
It's also a constraint that we can relax later when multitenancy is a bit more established and someone has a real issue with the limitation - it's not something we can ever claw back again if we allow some looking up projects by name with delimiters.<br>
<br>
I think for the time being it's an artificial constraint we should maintain.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> ><br>
> > This whole thing started by trying to distinguish a domain from a<br>
> > project within that domain that both have the same name. We can special<br>
> > case that, but it is not a great solution.<br>
> ><br>
> ><br>
> ><br>
> >><br>
> >> Henry<br>
> >><br>
> >>> On 5 Jun 2015, at 18:02, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a><br>
> >>> <mailto:<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>>> wrote:<br>
> >>><br>
> >>> On 06/03/2015 05:05 PM, Morgan Fainberg wrote:<br>
> >>>> Hi David,<br>
> >>>><br>
> >>>> There needs to be some form of global hierarchy delimiter - well<br>
> >>>> more to the point there should be a common one across OpenStack<br>
> >>>> installations to ensure we are providing a good and consistent (and<br>
> >>>> more to the point inter-operable) experience to our users. I'm<br>
> >>>> worried a custom defined delimiter (even at the domain level) is<br>
> >>>> going to make it difficult to consume this data outside of the<br>
> >>>> context of OpenStack (there are applications that are written to use<br>
> >>>> the APIs directly).<br>
> >>> We have one already. We are working JSON, and so instead of project<br>
> >>> name being a string, it can be an array.<br>
> >>><br>
> >>> Nothing else is backwards compatible. Nothing else will ensure we<br>
> >>> don;t break exisiting deployments.<br>
> >>><br>
> >>> Moving forward, we should support DNS notation, but it has to be an<br>
> >>> opt in<br>
> >>><br>
> >>>><br>
> >>>> The alternative is to explicitly list the delimiter in the project (<br>
> >>>> e.g. {"hierarchy": {"delim": ".", "domain.project.project2"}} ). The<br>
> >>>> additional need to look up the delimiter / set the delimiter when<br>
> >>>> creating a domain is likely to make for a worse user experience than<br>
> >>>> selecting one that is not different across installations.<br>
> >>>><br>
> >>>> --Morgan<br>
> >>>><br>
> >>>> On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick<br>
> >>>> <<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a> <mailto:<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>>> wrote:<br>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>> On 03/06/2015 14:54, Henrique Truta wrote:<br>
> >>>> > Hi David,<br>
> >>>> ><br>
> >>>> > You mean creating some kind of "delimiter" attribute in the domain<br>
> >>>> > entity? That seems like a good idea, although it does not<br>
> >>>> solve the<br>
> >>>> > problem Morgan's mentioned that is the global hierarchy delimiter.<br>
> >>>><br>
> >>>> There would be no global hierarchy delimiter. Each domain would<br>
> >>>> define<br>
> >>>> its own and this would be carried in the JSON as a separate<br>
> >>>> parameter so<br>
> >>>> that the recipient can tell how to parse hierarchical names<br>
> >>>><br>
> >>>> David<br>
> >>>><br>
> >>>> ><br>
> >>>> > Henrique<br>
> >>>> ><br>
> >>>> > Em qua, 3 de jun de 2015 às 04:21, David Chadwick<br>
> >>>> > <<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a> <mailto:<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>><br>
> >>>> <mailto:<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a><br>
> >>>> <mailto:<a href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>>>> escreveu:<br>
> >>>> ><br>
> >>>> ><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<br>
> >>>> want a<br>
> >>>> > domain, we<br>
> >>>> > > should always reference the namespace as we do today.<br>
> >>>> Basically, if we<br>
> >>>> > > ask for a project name we need to also provide it's<br>
> >>>> namespace (your<br>
> >>>> > > option #1). This clearly lines up with how we handle<br>
> >>>> projects in<br>
> >>>> > domains<br>
> >>>> > > today.<br>
> >>>> > ><br>
> >>>> > > I would, however, focus on how to represent the<br>
> >>>> namespace in a single<br>
> >>>> > > (usable) string. We've been delaying the work on this<br>
> >>>> for a while<br>
> >>>> > since<br>
> >>>> > > we have historically not provided a clear way to delimit the<br>
> >>>> > hierarchy.<br>
> >>>> > > If we solve the issue with "what is the delimiter"<br>
> >>>> between domain,<br>
> >>>> > > project, and subdomain/subproject, we end up solving the<br>
> >>>> usability<br>
> >>>> ><br>
> >>>> > why not allow the top level domain/project to define the<br>
> >>>> delimiter for<br>
> >>>> > its tree, and to carry the delimiter in the JSON as a new<br>
> >>>> 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<br>
> >>>> behavior you'd<br>
> >>>> > > expect with implementing option #2 (which at face value<br>
> >>>> feels to<br>
> >>>> > 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">henriquecostatruta@gmail.com</a><br>
> >>>> <mailto:<a href="mailto:henriquecostatruta@gmail.com">henriquecostatruta@gmail.com</a>><br>
> >>>> > <mailto:<a href="mailto:henriquecostatruta@gmail.com">henriquecostatruta@gmail.com</a><br>
> >>>> <mailto:<a href="mailto:henriquecostatruta@gmail.com">henriquecostatruta@gmail.com</a>>><br>
> >>>> > <mailto:<a href="mailto:henriquecostatruta@gmail.com">henriquecostatruta@gmail.com</a><br>
> >>>> <mailto:<a href="mailto:henriquecostatruta@gmail.com">henriquecostatruta@gmail.com</a>><br>
> >>>> > <mailto:<a href="mailto:henriquecostatruta@gmail.com">henriquecostatruta@gmail.com</a><br>
> >>>> <mailto:<a href="mailto:henriquecostatruta@gmail.com">henriquecostatruta@gmail.com</a>>>>> wrote:<br>
> >>>> > ><br>
> >>>> > > Hi folks,<br>
> >>>> > ><br>
> >>>> > ><br>
> >>>> > > In Reseller[1], we’ll have the domains concept<br>
> >>>> merged into<br>
> >>>> > projects,<br>
> >>>> > > that means that we will have projects that will<br>
> >>>> behave as domains.<br>
> >>>> > > Therefore, it will be possible to have two projects<br>
> >>>> with the same<br>
> >>>> > > name in a hierarchy, one being a domain and another<br>
> >>>> being a<br>
> >>>> > regular<br>
> >>>> > > project. For instance, the following hierarchy will<br>
> >>>> 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<br>
> >>>> a project<br>
> >>>> > scoped<br>
> >>>> > > token by name, once she’ll pass “domain = ‘A’” and<br>
> >>>> > <a href="http://project.name" target="_blank">project.name</a> <<a href="http://project.name/" target="_blank">http://project.name/</a>> <<a href="http://project.name" target="_blank">http://project.name</a><br>
> >>>> <<a href="http://project.name/" target="_blank">http://project.name/</a>>><br>
> >>>> > > <<a href="http://project.name" target="_blank">http://project.name</a> <<a href="http://project.name/" target="_blank">http://project.name/</a>>> = “A”.<br>
> >>>> Currently, we have no way to<br>
> >>>> > > distinguish which project we are referring to. We<br>
> >>>> have two<br>
> >>>> > proposals<br>
> >>>> > > for this.<br>
> >>>> > ><br>
> >>>> > ><br>
> >>>> > > 1.<br>
> >>>> > ><br>
> >>>> > > Specify the whole hierarchy in the token request<br>
> >>>> body, which<br>
> >>>> > > means that when requesting a token for the child<br>
> >>>> project for<br>
> >>>> > > that hierarchy, we’ll have in the scope field<br>
> >>>> 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<br>
> >>>> (project “B”, for<br>
> >>>> > > example), the hierarchy is optional.<br>
> >>>> > ><br>
> >>>> > ><br>
> >>>> > > 2.<br>
> >>>> > ><br>
> >>>> > > When a conflict happen, always provide a token<br>
> >>>> to the child<br>
> >>>> > > project. That means that, in case we have a name<br>
> >>>> clashing as<br>
> >>>> > > described, it will only be possible to get a<br>
> >>>> 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<br>
> >>>> create any more<br>
> >>>> > > restrictions than we already have. As a con, we<br>
> >>>> currently are not<br>
> >>>> > > able to get the names of projects in the hierarchy<br>
> >>>> above a given<br>
> >>>> > > project. Although the latter seems to hurt fewer<br>
> >>>> people, it<br>
> >>>> > has the<br>
> >>>> > > disadvantage of creating another set of constraints<br>
> >>>> that might<br>
> >>>> > > difficult the UX in the future.<br>
> >>>> > ><br>
> >>>> > ><br>
> >>>> > > What do you think about that? We want to hear your<br>
> >>>> oppinion, so we<br>
> >>>> > > can discuss it at today’s Keystone Meeting.<br>
> >>>> > ><br>
> >>>> > ><br>
> >>>> > > [1]<br>
> >>>> > ><br>
> >>>> ><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>
> >>>> ><br>
> >>>> __________________________________________________________________________<br>
> >>>> > > OpenStack Development Mailing List (not for usage<br>
> >>>> questions)<br>
> >>>> > > Unsubscribe:<br>
> >>>> > ><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>
> >>>> ><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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
> >>>> > ><br>
> >>>> ><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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
> >>>> > ><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>
> >>>> ><br>
> >>>> __________________________________________________________________________<br>
> >>>> > > OpenStack Development Mailing List (not for usage questions)<br>
> >>>> > > Unsubscribe:<br>
> >>>> ><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>
> >>>> ><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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
> >>>> > ><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>
> >>>> > OpenStack Development Mailing List (not for usage questions)<br>
> >>>> > Unsubscribe:<br>
> >>>> ><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>
> >>>> ><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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
> >>>> ><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:<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>
> >>>> 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:<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://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>
> >>> OpenStack Development Mailing List (not for usage questions)<br>
> >>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
> >>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<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>
> >> 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>
> > __________________________________________________________________________<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>
><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>
</div></div></blockquote></div><br></div></div>