Open Stack

> Josh raises a valid point in bug/1080921 -- nova-compute periodic
> tasks block incoming API requests from being handled, which is
> probably something that you'd never want to see happen in a
> production deployment.

I agree what we have currently is really sub-optimal for several
reasons, however there's a gap in my understanding here in terms
of API request dispatch being starved out when periodic tasks are
in flight.

If the periodic tasks are only executing in "greened" codepaths
(i.e. monkey-patched to use the co-operative yielding versions
of the standard libs), do we really see actual blocking of
API requests for the duration of the periodic task?

> What do people think about adding another nova service which runs
> beside nova-compute and runs periodic tasks which don't need any
> sort of shared global state with nova-compute? We could do it with a
> flag so that the default remains to use nova-compute for these
> periodic tasks, but if you "opt in" they're done with a
> nova-periodic instead.
>
> Thoughts?

That's an interesting idea. However I'd be a bit concerned about the
deployment complexity of yet another daemon on each compute node
(in addition to the nova-compute service and possibly also the ceilo
compute agent).

Perhaps this proliferation could be addressed by the ceilo compute
agent being realized simply as additional periodic tasks for this
new nova executor thingy.

However, we still wouldn't have addressed all the potential issues
with long-lived periodic tasks overlapping the configured interval,
and the implications for a predictable task cadence (needed for
ceilo polling).

Cheers,
Eoghan 

 
> Michael
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>