Open Stack

>
> 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"?
>
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.


> 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? Does it allow me
to replicate my projects? Does it allow me to work when there is no
connectivity between keystones? Does it allow me to know whether user
exists in the federated provider before I create shadow user? Does it
delete assignments/shadow user records when the user is deleted from the
remote provider? I can keep going forever. And yes, I don't mention CLI
support of federation.
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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andrey Grebennikov
Principal Deployment Engineer
Mirantis Inc, Austin TX
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161205/31ece96e/attachment.html>