[openstack-dev] A new nova service? nova-periodic?

Yun Mao yunmao at gmail.com
Tue Nov 20 03:30:01 UTC 2012


It seems that the fundamental problem is the lack of true parallelism, due
to eventlet and GIL, not lack of a new service. I personally feel like we
have enough services already. :) For example, we might be able fork a new
process and run all periodic tasks there. We'll probably hit some
concurrency bugs in the beginning either way.

Thanks,

Yun


On Mon, Nov 19, 2012 at 9:57 PM, Michael Still
<michael.still at canonical.com>wrote:

> I don't much mind what we call it by the way.
>
> 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.
>
> There's been some back and forth about this in terms of libvirt image
> cache management, but it seems that many of the periodic tasks fall into
> a category of "I want this to run, but I don't want to block servicing
> API requests for it".
>
> 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?
>
> Michael
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121119/eb021f1f/attachment.html>


More information about the OpenStack-dev mailing list