memcache test failing when system not in UTC

[Major Hayden]

I'm getting this test failure when running the tests from trunk on python 2.6:

======================================================================
FAIL: test_expired_token (test_backend_memcache.MemcacheToken)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/major/keystone/tests/test_backend.py", line 296, in test_expired_token
    self.token_api.get_token, token_id)
AssertionError: TokenNotFound not raised
----------------------------------------------------------------------

I dug into MemcacheClient.get in tests/test_backend_memcache.py and found that obj[1] > now returns true each time and no exception is raised.

I haven't found a fix but someone who is familiar with this code might find one a lot faster than I could.

[Major Hayden (rackerhacker)]

Got the test to pass on another box running python 2.6. I'll go back the drawing board and find out why it failed on the original server. :/

[Jay Pipes (jaypipes)]

I am seeing this on Python 2.7 locally.

[Joseph Heck (heckj)]

same here (python 2.7/mac) - reopening

[Chmouel Boudjnah (chmouel)]

Can we get a bit more info by any chance? what about if you clean your
virtualenv (.venv) environment ?

[Joseph Heck (heckj)]

Sorry Chmouel -here's some more detail.

I've done a full clear of the venv and run the tests through. It's completely repeatable on my laptop. I walked through the tests with pdb, and agonizingly enough, the code pass worked exactly as I expected when I was stepping through slowing and reading the code.

I can't imagine it's a "timing" thing after reading through the code, but that's what it appears to be. I was going to add logging to the tests and see what nose found for me while running full-bore (no dropping into pdb) to track this down.

If you have any brilliant insight, I'm all ears.

The tests *are* working 100% on my linux host where I do development, it's just not on my personal laptop.

[Major Hayden (rackerhacker)]

I have two Debian Squeeze VM's which both have python 2.6.6. The memcache tests passed on one VM but not the other. If I clear out the .venv on both and try again, I get the same failure. Both virtual environments contain the exact same python packages installed by pip (verified with a pip freeze).

I've tried just about everything I can think of to get the test to pass on the original server but I'm not having any luck.

[Major Hayden (rackerhacker)]

I may be onto something.

If I set the clock to CDT on the box which is *passing* the memcache test, it *fails*.
If I set the block back to UTC on that same box, the test *passes*.

Are we missing a timezone offset somewhere?

[Joseph Heck (heckj)]

Chmouel - this is irrespective of your recent patch, and exihibits all the way back to the merge of the redux branch, we just didn't have daylight saving time in effect that screwed with enough people's machines to make this visible.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/5290

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/5290
Committed: http://github.com/openstack/keystone/commit/dee81534cb2743262e2287da35e9b5970bd9cc12
Submitter: Jenkins
Branch: master

commit dee81534cb2743262e2287da35e9b5970bd9cc12
Author: Joe Heck <email address hidden>
Date: Tue Mar 13 13:53:40 2012 -0700

    making all use of time follow datetime.utcnow()
    fixes bug 954057

    Change-Id: I14fa475dc03410b8843ab028d30fbc8802c4be30