Do you mean project names or project IDs? Sam
> On 3 Jul 2015, at 12:12 am, Henrique Truta <henriquecostatr...@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@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
