Let's use skype Mine is nati.ueno
2012/7/5 Matt Joyce <[email protected]>: > 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 <[email protected]> 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 >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
