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.



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

Reply via email to