Open Stack

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