Open Stack

On 07/05/2012 03:12 PM, Matt Joyce wrote:
> Don't know if we want it.

So the justifications are:

1.  Redundancy
2.  Scalability
3.  Separation of concerns.

For example,  I could see a Set up where there are two Keystone servers 
with different back ends,  one using the corporate LDAP for in house 
use, one using a MySQL database for partners.

I could see variations where a Keystone instance gets deployed inside a 
corporate firewall,  using a strict auth mechanism like Kerberos or 
Smart Cards,  and those  tokens are used to talk to a remove Openstack 
install.  Again,  just for a subset of users.

>
> But we may want to consider the idea of satellite read only keystone 
> servers.

Not sure we can do strict read only, if the satellite serverws are 
responsible for issuing out tokens.

>
> 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 
> <mailto: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
>     <mailto:openstack at lists.launchpad.net>
>     Unsubscribe : https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     More help   : https://help.launchpad.net/ListHelp
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120705/db1c713b/attachment.html>