Hi, On 12/05/2016 09:20 PM, 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/ > <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)
What do you understand by "region"? > 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. My comment in the review still stands. With the change we are getting ourselves into situation when some tokens *are* verifiable in 2 regions (project-scoped with identical project ids in both regions), some *might be* verifiable in 2 regions (project-scoped with ids about which we can't tell anything), and some *are not* verifiable, because they are federation- or trust-scoped. A user (human or script) won't be able to tell what functionality the token brings without complex inspection. Current design is there is single issuer of tokens and single consumer. With the patch there will be single issuer and multiple consumers. Which is basically SSO, but done without explicit design decision. Here is what i suggest: 1. Stop thinking about 2 keystone installations with non-shared database as about "one single keystone". If there are 2 non-replicated databases, there are 2 separate keystones. 2 separate keystones have completely different sets of tokens. Do not try to share fernet keys between separate keystones. 2. Instead of implementing poor man's federation, use real federation. Create appropriate projects and create group-based assignments, one for each keystone instance. Use these group-based assignments for federated users. > 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: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