openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #14258
Re: Keystone Federation
Let's use skype
Mine is nati.ueno
2012/7/5 Matt Joyce <matt.joyce@xxxxxxxxxxxxxxxx>:
> Don't know if we want it.
>
> But we may want to consider the idea of satellite read only keystone
> servers.
>
> Mind you that may just be solving problems we don't even have yet.
>
> -Matt
>
>
> On Thu, Jul 5, 2012 at 11:26 AM, Adam Young <ayoung@xxxxxxxxxx> wrote:
>>
>> I am contemplating writing up a post-Folsom Blueprint for Keystone
>> Federation and /or replication, and would like to solicit input from the
>> community.
>>
>> With Signed tokens, we can provide the name of the Keystone server that
>> signed the token. With this comes the need to verify that the specified
>> Keystone server is a valid server. The logical way would be to check it
>> against the service catalog. I think the flow should go something like
>> this:
>>
>> when you start up a service like glance it should have a Keystone server
>> specified.
>>
>> When a token comes in with Keystone server that it does not recognize, it
>> queries the known Keystone server's service catalog to see if the keystone
>> server is a registered endpoint. This service catalog can get cached for
>> some short amount of time to ensure we don't trigger a flurry of activity on
>> a series of bogus requests.
>>
>> When a new Keystone server comes on line, it gets registered with an
>> existing Keystone server. At this point, it requests its token signing
>> certificate. Once it recieves the signing cert, an AMQP message then goes
>> out to the other Keystone servers announcing the new keystone service.
>>
>> Retirement of a Keystone server would be done in a similar way.
>>
>> There are three scenarios I could see:
>>
>> 1) No one Keystone server would hold a complete user or tenant list.
>> Instead, each would hold a subset of the tenants. A user might exist in
>> multiple Keystone databases if they are enrolled in multiple tenants, some
>> of which are in one Keystone, some of which are in another.
>>
>> 2) The entire user database is synchronized across all of the keystone
>> instances.
>>
>> 3) The Keystone instances use a single shared DBMS and are automatically
>> synchronized. Federation is just for redundancy and scaling.
>>
>> I don't want to build this just to build it. I'd like to know if A)
>> there is a real need for Keystone Federation and B) If anyone else has
>> thought through the problem and encountered issues I have not enumerated.
>> If there is enough interest, I will edit the discussion into a blueprint.
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References