I mean project names. You can, for example, create a project today with a
name like "dev/tests".
Em seg, 6 de jul de 2015 às 03:56, Sam Morrison
escreveu:
> Do you mean project names or project IDs?
>
> Sam
>
>
> On 3 Jul 2015, at 12:12 am, Henrique Truta
> 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
> [2]
> http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
