> > Just to clarify, the reason you want custom project IDs is so that when > you create a project in one region, you can create it again with the same > ID in another? Isn't that just manual replication though? > > What happens when there are projects in only one region? Or if that isn't > meant to happen, how would you make sure that doesn't happen? > Not quite sure I understand the point... Yes, this is exactly the reason why I need this feature. Project creation/replication is supposed to be done via external scripts. Currently I already have 2 slightly different use cases which definitely require this feature.
> > On 06/12/16 07:20, Andrey Grebennikov 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:unsubscribehttp://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 > > -- 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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
