Open Stack

-----Original Message-----
From: Andrey Grebennikov <agrebennikov at mirantis.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: December 5, 2016 at 12:22:09
To: openstack-dev at lists.openstack.org <openstack-dev at lists.openstack.org>
Subject:  [openstack-dev] [keystone] Custom ProjectID upon creation

> Hi keystoners,

I'm not a keystoner, but I hope youu don't mind my replying.

> 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/
>
> 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.

So this just doesn't sound right to me. You say above that there are
independent Keystone deployments in each region. What token type are
you using that each region could validate a token (assuming project
IDs that are identical across regions) that would do this for
"independent Keystone" deployments?

Specifically, let's presume you use Keystone's new default of fernet
tokens and you have independently deployed Keystone in each region.
Without synchronizing the keys Keystone uses to generate and validate
fernet tokens, I can't imagine how one token would work across all
regions. This sounds like a lofty goal.

Further, if Keystone is backed by LDAP, why are there projects being
created in the Keystone database at all? I thought using LDAP as a
backend would avoid that necessity. (Again, I'm not a keystone
developer ;))

> 2. Automated tools responsible for statistics collection may access all
> regions using one token (real customer's usecase)

Why can't the automated tools be updated to talk to each Keystone and
get a token while talking to that region?

> 3. Glance replication may happen because the images' parameter "owner"
> (which is a project) should be consistent across the regions.

So, Glance replication doesn't even guarantee identical image IDs
across regions. If Glance's replication isn't working because the
owner project is being synchronized directly, that sounds like a bug
in Glance, not Keystone.

> What I hear all time - "you have to replicate your database" which from the
> devops/deployment/operations perspective is totally wrong approach.

DevOps is a movement [1]. Replicating the database is not pleasant,
no, but it is your better option. I'll repeat, though, why is your
LDAP backed Keystone so reliant on Keystone's DB?

> 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.
>
> There is a long conversation in the comments of the review, mainly with
> concerns from cores (purely developer's opinions).

You say that as if developer opinions (the folks who have to
understand and maintain your desired approach) is invalid or
worthless. That's not the case.

> Please help me to bring it to life ;)

Please give us more detail and convince us to help you. :)

[1]: https://theagileadmin.com/what-is-devops/

--
Ian Cordasco