Open Stack

+1 to a fixture for the middleware if this is a common practice to do unit testing in this manner. The main issue here was mocking out the cache and using a hand-crafted “valid” token.

We have a mechanism provided in the keystone client library that allows for creating a valid token (all the required fields, etc): https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/fixture/v3.py#L48 for example.
—
Morgan Fainberg


From: Doug Hellmann doug.hellmann at dreamhost.com
Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev at lists.openstack.org
Date: May 30, 2014 at 14:08:16
To: OpenStack Development Mailing List (not for usage questions) openstack-dev at lists.openstack.org
Subject:  Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0  

Would it make sense to provide a test fixture in the middleware
library for projects who want or need to test with token management?

Doug

On Fri, May 30, 2014 at 12:49 PM, Brant Knudson <blk at acm.org> wrote:
>
> The auth_token middleware changed recently[1] to check if tokens retrieved
> from the cache are expired based on the expiration time in the token. The
> unit tests for Blazar, Ceilometer, and Ironic are all using a copy-pasted
> fake memcache implementation that's supposed to simulate what auth_token
> stores in the cache, but the tokens that it had stored weren't valid. Tokens
> have an expiration time in them and these ones didn't. I don't think that
> it's safe for test code to make assumptions about how the auth_token
> middleware is going to store data in its cache. The format of the cached
> data isn't part of the public interface. It's changed before, when
> expiration times changed from *nix timestamps to iso 8601 formatted dates.
>
> After looking at this, I proposed a couple of changes to the auth_token
> middleware. One is to have auth_token use the expiration time it has cached
> and fail the auth request if the token is expired according to the cache. It
> doesn't have to check the token's expiration time because it was stored as
> part of the cache data. The other is to make cached token handling more
> efficient by not checking the token expiration time if the token was cached.
>
> [1]
> http://git.openstack.org/cgit/openstack/python-keystoneclient/commit/keystoneclient/middleware/auth_token.py?id=8574256f9342faeba2ce64080ab5190023524e0a
> [2] https://review.openstack.org/#/c/96786/
>
> - Brant
>
>
>
> On Fri, May 30, 2014 at 7:11 AM, Sylvain Bauza <sbauza at redhat.com> wrote:
>>
>> Le 30/05/2014 14:07, Dina Belova a écrit :
>>
>> I did not look close to this concrete issue, but in the ceilometer there
>> is almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885
>> and fixes were already provided.
>>
>> Will this help Blazar?
>>
>>
>> Got the Ironic patch as well :
>>
>> https://review.openstack.org/#/c/96576/1/ironic/tests/api/utils.py
>>
>> Will provide a patch against Blazar.
>>
>> Btw, I'll close the bug.
>>
>>
>> -- Dina
>>
>>
>> On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza <sbauza at redhat.com> wrote:
>>>
>>> Hi Keystone developers,
>>>
>>> I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches
>>> are failing due to a new release in Keystone client which seems to
>>> regress on midleware auth.
>>>
>>> Do you have any ideas on if it's quick to fix, or shall I provide a
>>> patch to openstack/global-requirements.txt to only accept keystoneclient
>>> < 0.9.0 ?
>>>
>>> Thanks,
>>> -Sylvain
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>>
>> Best regards,
>>
>> Dina Belova
>>
>> Software Engineer
>>
>> Mirantis Inc.
>>
>>
>>
>> _______________________________________________
>> 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
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/9a8a4aef/attachment.html>