The ability to specify IDs at project creation time was proposed as a specification last summer [0]. The common theme from the discussion in that thread was to use shadow mapping [1] to solve that problem.
[0] https://review.openstack.org/#/c/323499/ [1] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/shadow-mapping.html On Mon, Dec 5, 2016 at 12:47 PM, Steve Martinelli <s.martine...@gmail.com> wrote: > I'm OK with the agreed approach in the patch, we restrict the ID being > specified to 32 character UUID4 string. And it only works on project > create, not update. > > On Mon, Dec 5, 2016 at 1:20 PM, Andrey Grebennikov < > agrebenni...@mirantis.com> wrote: > >> Hi keystoners, >> I'd like to open the discussion about the little feature which I'm trying >> to push forward for a while but I need some feedbacks/opinions/concerns >> regarding this. >> Here is the review I'm talking about https://review.openstack >> .org/#/c/403866/ >> >> What I'm trying to cover is multi-region deployment, which includes >> geo-distributed cloud with independent Keystone in every region. >> >> There is a number of use cases for the change: >> 1. Allow users to re-use their tokens in all regions across the >> distributed cloud. With global authentication (LDAP backed) and same roles >> names this is only one missing piece which prevents the user to switch >> between regions even withing single Horizon session. >> 2. Automated tools responsible for statistics collection may access all >> regions using one token (real customer's usecase) >> 3. Glance replication may happen because the images' parameter "owner" >> (which is a project) should be consistent across the regions. >> >> What I hear all time - "you have to replicate your database" which from >> the devops/deployment/operations perspective is totally wrong approach. >> If it is possible to avoid Galera replication over geographically >> distributed regions - then API calls should be used. Moreover, in case of 2 >> DCs there will be an issue to decide which region has to take over when >> they are isolated from each other. >> >> There is a long conversation in the comments of the review, mainly with >> concerns from cores (purely developer's opinions). >> >> Please help me to bring it to life ;) >> >> PS I'm so sorry, forgot to create a topic in the original message >> >> -- >> Andrey Grebennikov >> Principal Deployment Engineer >> Mirantis Inc, Austin TX >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
