Tests don't work on leapdays

[Sean Dague]

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.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[Thierry Carrez (ttx)]

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