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 = “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. 1. 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev