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