Sorry for my wrong mail 2012/7/5 Nachi Ueno <[email protected]>: > 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
