Open Stack

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.

1) Keystone becomes unavailable for a while
2) DB lookup is not possible directly by user_id in revoke tokens.

Atleast #2 should be fixed for DB query to succeed fast enough.

PS: We are using Folsom

Thanks,
-Ravi.


On Fri, Jun 14, 2013 at 1:43 PM, Dolph Mathews <dolph.mathews at gmail.com>wrote:

> 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:
>
>   The important distinction here is that the user requested side-effects,
> and can therefore be held accountable for them.
>
> 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 ?).
>
> In the mean time, the burden remains on the client to cache and recycle
> their own tokens.
>
>
> -Dolph
>
>
> On Fri, Jun 14, 2013 at 3:24 PM, Ravi Chunduru <ravivsn at gmail.com> wrote:
>
>> On the problem you described, I like the idea of configuration parameter
>> for what point we need to issue vs re-use.
>>
>> Thanks,
>> -Ravi.
>>
>>
>> On Fri, Jun 14, 2013 at 8:03 AM, Yee, Guang <guang.yee at hp.com> wrote:
>>
>>> 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. ****
>>>
>>> ** **
>>>
>>> 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?****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Guang****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Ravi Chunduru [mailto:ravivsn at gmail.com]
>>> *Sent:* Friday, June 14, 2013 7:32 AM
>>> *To:* OpenStack Development Mailing List
>>> *Subject:* Re: [openstack-dev] Expired tokens in Keystone****
>>>
>>> ** **
>>>
>>> I asked this question in different thread but no response.****
>>>
>>> ** **
>>>
>>> Why does keystone not re-use the token the one it has already issued for
>>> the same credentials. Any reason for not doing that?****
>>>
>>> ** **
>>>
>>> Thanks,****
>>>
>>> -Ravi.****
>>>
>>> On Wed, Jun 12, 2013 at 11:04 AM, Jay Pipes <jaypipes at gmail.com> wrote:*
>>> ***
>>>
>>> On 06/12/2013 12:54 PM, Craig E. Ward wrote:****
>>>
>>> I am working with a Folsom installation of OpenStack. The Keystone
>>> database (mysql) gets very large. The token table has millions of rows
>>> of expired tokens. Is there a reason not to delete these from the table?
>>> ****
>>>
>>> ** **
>>>
>>> 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.
>>>
>>> best,
>>> -jay****
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> --
>>> Ravi****
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Ravi
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ravi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130618/3e8e737e/attachment.html>