croniter cause alarm time constraint fail

[ZhiQiang Fan]

import croniter
import datetime
import pytz

start = '0 19 31 * *'
now = datetime.datetime(year=2015, month=3, day=31, hour=19, minute=30)
print 'utcnow', now
cron = croniter.croniter(start, now)
print cron.get_prev(datetime.datetime)
print cron.get_next(datetime.datetime)
print 'cron prev', cron.get_prev(datetime.datetime)

the output is:

utcnow 2015-03-31 19:30:00
2015-03-31 19:00:00
2015-05-31 19:00:00
cron prev 2015-05-01 19:00:00

This cause our alarm will not be triggered correctly

The solution may be in croniter, or we can examine the way we use it.

A workaround can be, copy that object in alarm evaluator: https://github.com/openstack/ceilometer/blob/7eee9fc8ac2ee1f3ed4cb6390875087737378c19/ceilometer/alarm/evaluator/__init__.py#L112

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/169713
Committed: https://git.openstack.org/cgit/openstack/ceilometer/commit/?id=2de5cfbd8c6ddbddff1aeef30027ffd85f9f5e78
Submitter: Jenkins
Branch: master

commit 2de5cfbd8c6ddbddff1aeef30027ffd85f9f5e78
Author: ZhiQiang Fan <email address hidden>
Date: Wed Apr 1 19:41:45 2015 +0800

    reset croniter to avoid cur time shift

    When we evaluate alarms, we check the time constraints, and will check
    if it is exactly match firstly, but croniter get_prev() and get_next() will
    change croniter.cur time, then if it is not exactly match, the cur time is
    no longer the current time, and the second call to get_prev() is not same
    as first get_prev(), finally, a wrong value may returned.

    For example, if start="0 11 31 * *", and current time is 2015-03-31T11:30:00,
    then first get_prev() is 2015-03-31T11:00:00, but second one is 2015-05-01T11:00:00

    This patch fixes it by creating a new croniter object with current time.

    Change-Id: Iaeb1f763ffc33b726d132a234c8e4e08db00a8fe
    Closes-Bug: #1438674