<div dir="ltr">Hey Jay,<div><br></div><div>Did you consider Swift's eventual consistency? The general use case for many OpenStack application is:</div><div> 1. obtain the token from Keystone</div><div> 2. perform some operation in OpenStack providing token as credentials.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>It is my understanding that Ceph exposing Swift API is not affected though, as it is strongly consistent.</div><div><br></div><div>Thanks,</div><div><br></div><div>Dmitry</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-29 20:12 GMT+04:00 Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Stackers,<br>
<br>
So, I had a thought this morning (uh-oh, I know...).<br>
<br>
What if we wrote a token driver in Keystone that uses Swift for backend storage?<br>
<br>
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.<br>
<br>
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...<br>
<br>
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.<br>
<br>
Best,<br>
-jay<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div>