On 06/06/2015 00:24, Adam Young wrote: > On 06/05/2015 01:15 PM, Henry Nash wrote: >> 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? > > 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.
+++1 > > 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. > > > >> >> Henry >> >>> On 5 Jun 2015, at 18:02, Adam Young <ayo...@redhat.com >>> <mailto:ayo...@redhat.com>> wrote: >>> >>> On 06/03/2015 05:05 PM, Morgan Fainberg wrote: >>>> Hi David, >>>> >>>> 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). >>> We have one already. We are working JSON, and so instead of project >>> name being a string, it can be an array. >>> >>> Nothing else is backwards compatible. Nothing else will ensure we >>> don;t break exisiting deployments. >>> >>> Moving forward, we should support DNS notation, but it has to be an >>> opt in >>> >>>> >>>> The alternative is to explicitly list the delimiter in the project ( >>>> e.g. {"hierarchy": {"delim": ".", "domain.project.project2"}} ). 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. >>>> >>>> --Morgan >>>> >>>> On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick >>>> <d.w.chadw...@kent.ac.uk <mailto:d.w.chadw...@kent.ac.uk>> wrote: >>>> >>>> >>>> >>>> On 03/06/2015 14:54, Henrique Truta wrote: >>>> > Hi David, >>>> > >>>> > 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. >>>> >>>> There would be no global hierarchy delimiter. Each domain would >>>> define >>>> its own and this would be carried in the JSON as a separate >>>> parameter so >>>> that the recipient can tell how to parse hierarchical names >>>> >>>> David >>>> >>>> > >>>> > Henrique >>>> > >>>> > Em qua, 3 de jun de 2015 às 04:21, David Chadwick >>>> > <d.w.chadw...@kent.ac.uk <mailto:d.w.chadw...@kent.ac.uk> >>>> <mailto:d.w.chadw...@kent.ac.uk >>>> <mailto:d.w.chadw...@kent.ac.uk>>> escreveu: >>>> > >>>> > >>>> > >>>> > On 02/06/2015 23:34, Morgan Fainberg wrote: >>>> > > Hi Henrique, >>>> > > >>>> > > I don't think we need to specifically call out that we >>>> want a >>>> > domain, we >>>> > > should always reference the namespace as we do today. >>>> Basically, if we >>>> > > ask for a project name we need to also provide it's >>>> namespace (your >>>> > > option #1). This clearly lines up with how we handle >>>> projects in >>>> > domains >>>> > > today. >>>> > > >>>> > > I would, however, focus on how to represent the >>>> namespace in a single >>>> > > (usable) string. We've been delaying the work on this >>>> for a while >>>> > since >>>> > > we have historically not provided a clear way to delimit the >>>> > hierarchy. >>>> > > If we solve the issue with "what is the delimiter" >>>> between domain, >>>> > > project, and subdomain/subproject, we end up solving the >>>> usability >>>> > >>>> > why not allow the top level domain/project to define the >>>> delimiter for >>>> > its tree, and to carry the delimiter in the JSON as a new >>>> parameter. >>>> > That provides full flexibility for all languages and locales >>>> > >>>> > David >>>> > >>>> > > issues with proposal #1, and not breaking the current >>>> behavior you'd >>>> > > expect with implementing option #2 (which at face value >>>> feels to >>>> > be API >>>> > > incompatible/break of current behavior). >>>> > > >>>> > > Cheers, >>>> > > --Morgan >>>> > > >>>> > > On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta >>>> > > <henriquecostatr...@gmail.com >>>> <mailto:henriquecostatr...@gmail.com> >>>> > <mailto:henriquecostatr...@gmail.com >>>> <mailto:henriquecostatr...@gmail.com>> >>>> > <mailto:henriquecostatr...@gmail.com >>>> <mailto:henriquecostatr...@gmail.com> >>>> > <mailto:henriquecostatr...@gmail.com >>>> <mailto:henriquecostatr...@gmail.com>>>> wrote: >>>> > > >>>> > > Hi folks, >>>> > > >>>> > > >>>> > > In Reseller[1], we’ll have the domains concept >>>> merged into >>>> > projects, >>>> > > that means that we will have projects that will >>>> behave as domains. >>>> > > Therefore, it will be possible to have two projects >>>> with the same >>>> > > name in a hierarchy, one being a domain and another >>>> being a >>>> > regular >>>> > > project. For instance, the following hierarchy will >>>> be valid: >>>> > > >>>> > > A - is_domain project, with domain A >>>> > > >>>> > > | >>>> > > >>>> > > B - project >>>> > > >>>> > > | >>>> > > >>>> > > A - project with domain A >>>> > > >>>> > > >>>> > > That hierarchy faces a problem when a user requests >>>> a project >>>> > scoped >>>> > > token by name, once she’ll pass “domain = ‘A’” and >>>> > project.name <http://project.name/> <http://project.name >>>> <http://project.name/>> >>>> > > <http://project.name <http://project.name/>> = “A”. >>>> Currently, we have no way to >>>> > > distinguish which project we are referring to. We >>>> have two >>>> > proposals >>>> > > for this. >>>> > > >>>> > > >>>> > > 1. >>>> > > >>>> > > Specify the whole hierarchy in the token request >>>> body, which >>>> > > means that when requesting a token for the child >>>> project for >>>> > > that hierarchy, we’ll have in the scope field >>>> something like: >>>> > > >>>> > > "project": { >>>> > > "domain": { >>>> > > "name": "A" >>>> > > }, >>>> > > "name": [“A”', “B”, “A”] >>>> > > } >>>> > > >>>> > > >>>> > > If the project name is unique inside the domain >>>> (project “B”, for >>>> > > example), the hierarchy is optional. >>>> > > >>>> > > >>>> > > 2. >>>> > > >>>> > > When a conflict happen, always provide a token >>>> to the child >>>> > > project. That means that, in case we have a name >>>> clashing as >>>> > > described, it will only be possible to get a >>>> project scoped >>>> > > token to the is_domain project through its id. >>>> > > >>>> > > >>>> > > >>>> > > The former will give us more clarity and won’t >>>> create any more >>>> > > restrictions than we already have. As a con, we >>>> currently are not >>>> > > able to get the names of projects in the hierarchy >>>> above a given >>>> > > project. Although the latter seems to hurt fewer >>>> people, it >>>> > has the >>>> > > disadvantage of creating another set of constraints >>>> that might >>>> > > difficult the UX in the future. >>>> > > >>>> > > >>>> > > What do you think about that? We want to hear your >>>> oppinion, so we >>>> > > can discuss it at today’s Keystone Meeting. >>>> > > >>>> > > >>>> > > [1] >>>> > > >>>> > >>>> >>>> https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst >>>> > > >>>> > > >>>> > > >>>> > >>>> >>>> __________________________________________________________________________ >>>> > > OpenStack Development Mailing List (not for usage >>>> questions) >>>> > > Unsubscribe: >>>> > > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>> > >>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> >>>> > > >>>> > >>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> >>>> > > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > >>>> >>>> __________________________________________________________________________ >>>> > > OpenStack Development Mailing List (not for usage questions) >>>> > > Unsubscribe: >>>> > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>> > >>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> >>>> > > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > > >>>> > >>>> > >>>> >>>> __________________________________________________________________________ >>>> > OpenStack Development Mailing List (not for usage questions) >>>> > Unsubscribe: >>>> > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>> > >>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> >>>> > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> > >>>> > >>>> > >>>> >>>> __________________________________________________________________________ >>>> > OpenStack Development Mailing List (not for usage questions) >>>> > Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org >>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev