Open Stack

Adam:

I think this is a topic that I would like to review with you.  I believe
that there is a need for the type of federation you are describing. 

Regards, Marc

J. Marc Edwards, 
Lead Architect
Semiconductor Design Portals
Nimbis Services, Inc.
1140 Kildaire Farm Road, Suite 108-12
Cary, NC 27519

Cell  - (919) 345-1021
Fax   - (919) 882-8602
Skype - (919) 747-3775
jmarcedwards at gmail.com
marc.edwards at nimbisservices.com

 


-----Original Message-----
From: openstack-bounces+marc.edwards=nimbisservices.com at lists.launchpad.net
[mailto:openstack-bounces+marc.edwards=nimbisservices.com at lists.launchpad.ne
t] On Behalf Of Adam Young
Sent: Thursday, July 05, 2012 2:26 PM
To: openstack
Subject: [Openstack] Keystone Federation

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