Open Stack

On Thu, Jun 12, 2014 at 10:05 PM, Tom Cammann <tom.cammann at hp.com> wrote:
> Hello,
>
> I'm addressing https://bugs.launchpad.net/oslo/+bug/1326020 which is
> dealing with periodic tasks.
>
> There is currently a code block that checks if a task is 0.2 seconds
> away from being run and if so it run now instead. Essentially
> coalescing nearby tasks together.
>
> From oslo-incubator/openstack/common/periodic_task.py:162
>
> # If a periodic task is _nearly_ due, then we'll run it early
> idle_for = min(idle_for, spacing)
> if last_run is not None:
>     delta = last_run + spacing - time.time()
>     if delta > 0.2:
>         idle_for = min(idle_for, delta)
>         continue
>
> However the resolution in the config for various periodic tasks is by
> the second, and I have been unable to find a task that has a
> millisecond resolution. I intend to get rid of this coalescing in this
> bug fix.
>
> It fits in with this bug fix as I intend to make the tasks run on their
> specific spacing boundaries, i.e. if spacing is 10 seconds, it will run
> at 17:30:10, 17:30:20, etc.
>
> Is there any reason to keep the coalescing of tasks?

The resolution for periodic tasks is seconds, but a task can take a
non-integer number of seconds to have run. This code was added (IIRC,
it was a long time ago) in an attempt to detect tasks that were about
to run and kick them off straight away instead of doing very small
sleeps. I think that's probably bogus, and I'm ok with you removing
it.

The historical context here is that periodic tasks used to have very
unpredictable frequencies, you'd specify the number of periodic task
loop "ticks" you wanted as a frequency, but that wasn't a predictable
time because sometimes the periodic task loop was busier than others.
Additionally, the spacing didn't take into account how long the jobs
took to run, so if you specified 10 ticks, that was a 10 tick wait
between runs, even if the last run took an hour. So... I think I was a
little focused on timing when I wrote this code, and probably went too
far in the other direction.

Cheers,
Michael

-- 
Rackspace Australia