Hey Jay, Did you consider Swift's eventual consistency? The general use case for many OpenStack application is: 1. obtain the token from Keystone 2. perform some operation in OpenStack providing token as credentials.
As a result of operation #1 the token will be saved into Swift by the Keystone. But due to eventual consistency it could happen that validation of token in operation #2 will not see the saved token. Probability depends on time gap between ops #1 and #2: the smaller the gap, the higher is probability (less time to sync). Also it depends on Swift installation size: the bigger is installation, the higher is probability (bigger 'space' for inconsistency). I believe that I've seen such inconsistency in Rackspace Cloud Files a couple of years ago. We uploaded a file using an application into the Files, but saw it in browser only a couple minutes later. It is my understanding that Ceph exposing Swift API is not affected though, as it is strongly consistent. Thanks, Dmitry 2014-09-29 20:12 GMT+04:00 Jay Pipes <jaypi...@gmail.com>: > Hey Stackers, > > So, I had a thought this morning (uh-oh, I know...). > > What if we wrote a token driver in Keystone that uses Swift for backend > storage? > > I have long been an advocate of the memcache token driver versus the SQL > driver for performance reasons. However, the problem with the memcache > token driver is that if you want to run multiple OpenStack regions, you > could share the identity data in Keystone using replicated database > technology (mysql galera/PXC, pgpool II, or even standard mysql > master/slave), but each region needs to have its own memcache service for > tokens. This means that tokens are not shared across regions, which means > that users have to log in separately to each region's dashboard. > > I personally considered this a tradeoff worth accepting. But then, today, > I thought... what about storing tokens in a globally-distributed Swift > cluster? That would take care of the replication needs automatically, since > Swift would do the needful. And, add to that, Swift was designed for > storing lots of small objects, which tokens are... > > Thoughts? I think it would be a cool dogfooding effort if nothing else, > and give users yet another choice in how they handle multi-region tokens. > > Best, > -jay > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
