<br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 1:06 AM, Kieran Spear <span dir="ltr"><<a href="mailto:kispear@gmail.com" target="_blank">kispear@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi all,<br>
<br>
I want to backport the fix for the "Token List in Memcache can consume<br>
an entire memcache page" bug[1] to Grizzly, but I had a couple of<br>
questions:<br>
<br>
1. Why do we need to store the entire token data in the<br>
usertoken-<userid> key? This data always seems to be hashed before<br>
indexing into the 'token-<tokenid>' keys anyway. The size of the<br>
memcache data for a user's token list currently grows by 4k every time<br>
a new PKI token is created. It doesn't take long to hit 1MB at this<br>
rate even with the above fix.<br>
<br>
2. Every time it creates a new token, Keystone loads each token from<br>
the user's token list with a separate memcache call so it can throw it<br>
away if it's expired. This seems excessive. Is it anything to worry<br>
about? If it just checked the first two tokens you'd get the same<br>
effect on a longer time scale.<br>
<br>
I guess part of the answer is to decrease our token expiry time, which<br>
should mitigate both issues. Failing that we'd consider moving to the<br>
SQL backend.<br>
<br>
Cheers,<br>
Kieran<br>
<br>
[1] <a href="https://bugs.launchpad.net/keystone/+bug/1171985" target="_blank">https://bugs.launchpad.net/keystone/+bug/1171985</a><br>
<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>
</blockquote></div><br><div>Hi Kieran,</div><div><br></div><div>I'd be happy to help you with the backporting of this fix if you need any assistance.</div><div><br></div><div>Here are some quick answers to your questions:</div>

<div><br></div><div>1. The individual tokens are stored in independent keys in their entirety, since the memcache backend replaces the SQL backend.  In the usertoken-<userid> we should only be storing the hashed value.  It looks like there is a bug there (I'll check and get a fix proposed in gerrit today to address this).</div>

<div><br></div><div>2.  There has been a lot of discussion on this topic and some other solutions have been proposed (such as use a clock-mechanism to expire tokens, etc).  However, to stay compatible with the current business logic, which requires the ability to revoke subsets of tokens for the user (instead. all tokens for the user on every change to the user's roles/project associations, etc), a list of current tokens for the user must be maintained.  Ideally, the token list shouldn't ever be massive, meaning the extra calls to memcache should be limited.  The general plan is to develop another approach to solve this issue without the need of keeping a user-token-list, but it just wasn't viewed as possible for Havana.  Checking the first two tokens wouldn't exactly solve the issue, as tokens can in theory be requested with varying expiration times; this means that tokens in the middle of the list could be expired whereas the tokens at the start of the list are invalid.</div>

<div><br></div><div>Keeping the expiry time low is definitely a good idea.</div><div><br></div><div><br></div><div>Let me know if you want any further details.  I'd be happy to elaborate / fill-in more.</div><div><br>

</div><div>Cheers,</div><div>Morgan Fainberg</div>