Open Stack

Hi everyone,

In Kilo, keystone introduced the concept of Hierarchical Multitenancy[1],
which allows cloud operators to organize projects in hierarchies. This
concept is evolving in Liberty, with the addition of the Reseller use
case[2], where among other features, it’ll have hierarchies of domains by
making the domain concept a feature of projects and not a different entity:
from now on, every domain will be treated as a project that has the
“is_domain” property set to True.

Currently, getting a project scoped token can be made by only passing the
project name and the domain it belongs to, once project names are unique
between domains. However with those hierarchies of projects, in M we intend
to remove this constraint in order to make a project name unique only in
its level in the hierarchy (project parent). In other words, it won’t be
possible to have sibling projects with the same name. For example. the
following hierarchy will be valid:

               A - project with the domain feature

             /    \

            B   C   - “pure” projects, children of A

            |      |

           A     B  - “pure” projects, children of B and C respectively

Therefore, the cloud user faces some problems when getting a project scoped
token by name to projects A or B, since keystone won’t be able to
distinguish them only by their names. The best way to solve this problem is
providing the full hierarchy, like “A/B/A”, “A/B”, “A/C/B” and so on.

To achieve this, we intend to deprecate the “/” character in project names
in Liberty and prohibit it in M, removing/replacing this character in a
database migration**.

Do you have some strong reason to keep using this character in project
names? How bad would it be for existing deploys? We’d like to hear from
you.

Best regards,

Henrique

** LDAP as assignment backend does not support Hierarchical Multitenancy.
This change will be only applied to SQL backends.

[1]
http://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html

[2]
http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150702/076ed432/attachment.html>