<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/05/2012 03:12 PM, Matt Joyce
wrote:<br>
</div>
<blockquote
cite="mid:CAGYSk8eSq=WV0c9eFM+48L6tdd8QCh=jqCF2mZhwDueUOaeLkw@mail.gmail.com"
type="cite">Don't know if we want it.<br>
</blockquote>
<br>
So the justifications are:<br>
<br>
1. Redundancy<br>
2. Scalability<br>
3. Separation of concerns.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAGYSk8eSq=WV0c9eFM+48L6tdd8QCh=jqCF2mZhwDueUOaeLkw@mail.gmail.com"
type="cite"><br>
But we may want to consider the idea of satellite read only
keystone servers.<br>
</blockquote>
<br>
Not sure we can do strict read only, if the satellite serverws are
responsible for issuing out tokens.<br>
<br>
<blockquote
cite="mid:CAGYSk8eSq=WV0c9eFM+48L6tdd8QCh=jqCF2mZhwDueUOaeLkw@mail.gmail.com"
type="cite"><br>
Mind you that may just be solving problems we don't even have yet.<br>
<br>
-Matt<br>
<br>
<div class="gmail_quote">
On Thu, Jul 5, 2012 at 11:26 AM, Adam Young <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:ayoung@redhat.com"
target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I am contemplating writing up a post-Folsom Blueprint for
Keystone Federation and /or replication, and would like to
solicit input from the community.<br>
<br>
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:<br>
<br>
when you start up a service like glance it should have a
Keystone server specified.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Retirement of a Keystone server would be done in a similar
way.<br>
<br>
There are three scenarios I could see:<br>
<br>
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.<br>
<br>
2) The entire user database is synchronized across all of the
keystone instances.<br>
<br>
3) The Keystone instances use a single shared DBMS and are
automatically synchronized. Federation is just for redundancy
and scaling.<br>
<br>
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.<br>
<br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
</body>
</html>