Open Stack

Do you mean project names or project IDs?

Sam


> On 3 Jul 2015, at 12:12 am, Henrique Truta <henriquecostatruta at gmail.com> wrote:
> 
> 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 <http://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html>
> [2] http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html <http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150706/54009500/attachment.html>