Tests don't work on leapdays

Bug #1551189 reported by Sean Dague on 2016-02-29
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Matthew Edmonds

Bug Description

2016-02-29 08:57:08.024 | Captured traceback:
2016-02-29 08:57:08.025 | ~~~~~~~~~~~~~~~~~~~
2016-02-29 08:57:08.025 | Traceback (most recent call last):
2016-02-29 08:57:08.042 | File "keystone/tests/unit/test_backend.py", line 5555, in test_list_trust_by_trustor
2016-02-29 08:57:08.042 | self.create_sample_trust(uuid.uuid4().hex)
2016-02-29 08:57:08.042 | File "keystone/tests/unit/test_backend.py", line 5475, in create_sample_trust
2016-02-29 08:57:08.042 | expires_at = datetime.datetime.utcnow().replace(year=2031)
2016-02-29 08:57:08.042 | ValueError: day is out of range for month

The keystone test code assume all months have the same length in all years. That is not the case.

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

Changed in keystone:
assignee: nobody → Sean Dague (sdague)
status: New → In Progress
Sean Dague (sdague) on 2016-02-29
Changed in keystone:
status: In Progress → Confirmed
importance: Undecided → High
Changed in keystone:
assignee: Sean Dague (sdague) → Matthew Edmonds (edmondsw)
status: Confirmed → In Progress
Changed in keystone:
milestone: none → mitaka-3

Reviewed: https://review.openstack.org/285987
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=7c6556ce18eb170fd8102168b33a50272b22ec5a
Submitter: Jenkins
Branch: master

commit 7c6556ce18eb170fd8102168b33a50272b22ec5a
Author: Sean Dague <email address hidden>
Date: Mon Feb 29 06:31:40 2016 -0500

    Make keystone tests work on leap years

    A bunch of tests have to do with fast forwarding time to figure out
    what happens with expirations. That is done with a naive .replace on
    year. Which is fine, except on Feb 29th, because the python code does
    care if something is a valid datetime. Previously 2030 and 2031 were
    used as magic years. Neither is a leap year. Fast forwarding to that
    year on Feb 29th is a fatal python error.

    Narrowly fix this by using 2028 and 2032 instead. A better solution
    should probably be implemented long-term, but until this is landed
    keystone is blocked.

    Change-Id: If13e53bd5d4ace2a53a245d74166e4f3b1c34d4a
    Closes-Bug: #1551189

Changed in keystone:
status: In Progress → Fix Released

This issue was fixed in the openstack/keystone development milestone.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers