On 12/06/2016 01:46 AM, Andrey Grebennikov wrote: > 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/> > > <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"? > > I believe I explained what the "region" is in the beginning. In here it > is actually a generic "keystone region" with all stuff, but Keystone is > independent in it. Literally all Keystones in all "my" regions are aware > about each other since they all have common catalog. > > > > 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. > > I commented it in the IRC and repeat over here - it is Always the > responsibility of the administrator to realize how things work and > implement it in the way he/she wants it. You don't need it - you don't > set it. The IDs will be still generated.
It is not a general usecase that an administrator creates projects. There are policies that define who can do that. > > 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. > > Not true. SSO assumes Central point of authorization. Here it is highly > distributed. > > > 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. > > Even if you replicate the DB it is not going to work with no key > replication. I repeat my statement once again - if the admin doesn't > need it - leave the --id field blank, that's it. Nothing is broken. > > > 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. > > Does federation currently allow me to use remote groups? What do you mean by remote groups? Group name can be specified in SAML assertion and then used, yes. > Does it allow me to replicate my projects? No. Create projects in each keystone: for ip in $list_of_ips; do openstack project create --os-url=$ip ...; done > Does it allow me to work when there is no connectivity between keystones? Yes > Does it allow me to know whether user > exists in the federated provider before I create shadow user? I don't understand the question. Shadow users don't need to be created. Shadow users is internal keystone entity that operator doesn't deal with at all. > Does it > delete assignments/shadow user records when the user is deleted from the > remote provider? No, but this is merely a clean-up problem. If remote user doesn't exist, the local user is effectively disabled. And there are no assignments for a shadow federated user, only for the group. > I can keep going forever. Please do! > And yes, I don't mention CLI > support of federation. What's wrong with it? If there is something missing, you're welcome to file a bugreport and/or start working on it in python-openstackclient. > Feel free to add. > > Thanks! > > > 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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 > __________________________________________________________________________ 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