<br><br>On Monday, September 29, 2014, Julien Danjou <<a href="mailto:julien@danjou.info">julien@danjou.info</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Sep 29 2014, Jay Pipes wrote:<br>
<br>
> Any objection to me taking up the work? Was there any associated blueprint for<br>
> it?<br>
<br>
As said on IRC, go ahead. There's no blueprint associated AFAIK. :)<br>
<br>
--<br>
Julien Danjou<br>
/* Free Software hacker<br>
   <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a> */<br>
</blockquote><div><br></div><div>There is of course a benefit to having more options for deployers to utilize for the token persistence, especially if we solve complaints about the current token systems in the process. <span></span></div><div><br></div><div>A couple thoughts:</div><div><br></div><div>I highly recommend making this a dogpile backend (KVS) in keystone. It should help eliminate a bunch of the harder bits of code since it will use the KVS house keeping code for the indexes (same way it works in memcache or the in-memory dict backend). </div><div><br></div><div>The big issue you're going to run into is locking. The indexes need to have a distributed lock that guarantees that each index is read/updated/released atomically (similar to the SQL transaction). The way memcache and redis handle this is by trying to add a record that is based on the index record name and if that "add" fails (already exists) we assume the referenced record is locked. We automatically timeout the lock after a period of time. </div><div><br></div><div>I am also curious what the performance profile of swift-as-a-token-backend will look like. You are adding a large amount of overhead to the request (in theory) as the swift call is another http request. And depending on how swift is running, may require more token request work (tokens, especially v2.0 since he token is is in the body must be considered secure data, and therefore should not be directly accessible to the world at large), keeping security concerns in mind. </div><br><div>There are some other cool ideas this can lead to, but let's talk about the reality and limitations (and how we solve those issues) for our current use cases before we dive into the next steps. </div><div><br></div><div>The first thing we will need is (of course) a spec for keystone. Let's try and get the spec proposed soon so we can ensure that we get anything that needs to land in kilo through the door earlier in the cycle. </div><div><br></div><div>Cheers,</div><div>Morgan</div><div><br></div><div>Sent via mobile </div>