Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150602/0b0bf5af/attachment.html>