Open Stack

Let's use skype

Mine is nati.ueno

2012/7/5 Matt Joyce <matt.joyce at cloudscaling.com>:
> 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 at redhat.com> 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 at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>