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

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>