Open Stack

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<https://launchpad.net/%7Eopenstack>
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/%7Eopenstack>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120705/b0ec5151/attachment.html>