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 <sorri...@gmail.com> escreveu: > 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 > [2] > http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
