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.
Henrique Em qua, 3 de jun de 2015 às 04:21, David Chadwick <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>> > 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> = “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://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