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 <ayo...@redhat.com
<mailto:ayo...@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@lists.launchpad.net
<mailto:openstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack>
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
