Open Stack

Sorry, didn't notice the list changed.

On Fri, Jun 13, 2014 at 8:40 AM, Michael Still <mikal at stillhq.com> wrote:
> 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



-- 
Rackspace Australia