Open Stack

> > > But I'm not sure that we can always address (b) or (c) even with
> > > a special thread for high-priority/time-sensitive tasks.
> > 
> > We can't do anything about (b), except starting the task again
> > while the
> > previous one is not finished. Is that desirable?
> > - Yes if your task is taking much time because of blocked I/O (i.e.
> > long
> >   round-trip);
> > - No if your task is taking much time because of system load.
> 
> For nova's periodic task implementation, it's a bit different to. In
> nova, all periodic_task are organized as a list and are executed in
> one timer (nova/service.py) through one Looping call
> So in nova, (b) is "summary (all periodic task execute time) <
> periodic_interval", and which will be easier to fulfill, after all,
>  if this happen, it means the periodic_interval should be adjusted .

By "the periodic_interval should be adjusted", you mean that the
entire set of periodic tasks should be put on a slower cadence?

This may not be acceptable, if certain tasks really need to run
at a certain frequency (e.g. reporting something every minute).

Now of course we can only adjust the sleep interval to take account of
the tasks run duration if the difference between the former and the
latter is positive. If it turns out negative, then the next task runs
are inevitably going to be skewed from the wall-clock boundary.

But we could make this a bit less likely by running the periodic tasks
in parallel instead of serially, in which case it would require a
single tasks's duration to exceed the periodic interval before we'd
have an issue (and then only this individual task would execute late
on the next iteration, assuming we'd never want individual task runs
to overlap).

Cheers,
Eoghan