The important point I want to make is availability of service, if there are too many client requests to keystone, it ends up creating too many tokens. Under such circumstances, when user runs keystone command like user role add which makes keystone to revoke tokens for given user id and tenant id making it unresponsive for several minutes depending on number of tokens.<div>
<br></div><div>1) Keystone becomes unavailable for a while</div><div>2) DB lookup is not possible directly by user_id in revoke tokens.</div><div><br></div><div>Atleast #2 should be fixed for DB query to succeed fast enough. </div>
<div><br></div><div>PS: We are using Folsom</div><div><br></div><div>Thanks,</div><div>-Ravi.<br><div><br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 1:43 PM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The token creation API (e.g. POST /v2.0/tokens and POST /v3/auth/tokens) is not intended to be idempotent. To rephrase RFC 2616 a bit:<div>
<br></div><div> The important distinction here is that the user requested side-effects, and can therefore be held accountable for them.</div>
<div><br></div><div>Changing this behavior represents a change to the API, not just it's implementation. I don't see how you could make such a change in a backwards compatible manner (if a client intends to create multiple tokens, you would be breaking them) without introducing a whole new call (e.g. PUT /v3/auth/tokens ?).</div>
<div><br></div><div>In the mean time, the burden remains on the client to cache and recycle their own tokens.</div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><br></div>
-Dolph</div></font></span><div><div class="h5">
<br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 3:24 PM, Ravi Chunduru <span dir="ltr"><<a href="mailto:ravivsn@gmail.com" target="_blank">ravivsn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the problem you described, I like the idea of configuration parameter for what point we need to issue vs re-use.<div><br></div><div>Thanks,</div><div>-Ravi.<div><div><br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 8:03 AM, Yee, Guang <span dir="ltr"><<a href="mailto:guang.yee@hp.com" target="_blank">guang.yee@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think there was a case in which user started a VM snapshot in Nova with a to-be-expired token and by the time the snapshot reached Glance the token had already expired. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">But I like the idea of token reuse. Probably need a configurable parameter to determine at what point we need to issue a new token versus reusing an existing one. Maybe a good topic for the next Summit?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Guang<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ravi Chunduru [mailto:<a href="mailto:ravivsn@gmail.com" target="_blank">ravivsn@gmail.com</a>] <br>
<b>Sent:</b> Friday, June 14, 2013 7:32 AM<br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] Expired tokens in Keystone<u></u><u></u></span></p></div><div><div><p class="MsoNormal">
<u></u> <u></u></p><p class="MsoNormal">I asked this question in different thread but no response.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Why does keystone not re-use the token the one it has already issued for the same credentials. Any reason for not doing that?<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks,<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-bottom:12.0pt">-Ravi.<u></u><u></u></p><div><p class="MsoNormal">On Wed, Jun 12, 2013 at 11:04 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<u></u><u></u></p>
<div><p class="MsoNormal">On 06/12/2013 12:54 PM, Craig E. Ward wrote:<u></u><u></u></p><p class="MsoNormal">I am working with a Folsom installation of OpenStack. The Keystone<br>database (mysql) gets very large. The token table has millions of rows<br>
of expired tokens. Is there a reason not to delete these from the table?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">Not unless you need them for some security auditing purpose... and if you don't, I recommend switching to the memcache token driver. It's faster and doesn't have the drawback of filling up your identity database will millions of token records.<br>
<br>best,<br>-jay<u></u><u></u></p><div><div><p class="MsoNormal"><br><br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p></div></div></div><p class="MsoNormal"><br>
<br clear="all"><u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <br>Ravi<u></u><u></u></p></div></div></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ravi<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ravi<br>
</div></div>