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.<div>
<br></div><div>Thanks,</div><div><br></div><div>Yun</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 9:57 PM, Michael Still <span dir="ltr"><<a href="mailto:michael.still@canonical.com" target="_blank">michael.still@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't much mind what we call it by the way.<br>
<br>
Josh raises a valid point in bug/1080921 -- nova-compute periodic tasks<br>
block incoming API requests from being handled, which is probably<br>
something that you'd never want to see happen in a production deployment.<br>
<br>
There's been some back and forth about this in terms of libvirt image<br>
cache management, but it seems that many of the periodic tasks fall into<br>
a category of "I want this to run, but I don't want to block servicing<br>
API requests for it".<br>
<br>
What do people think about adding another nova service which runs beside<br>
nova-compute and runs periodic tasks which don't need any sort of shared<br>
global state with nova-compute? We could do it with a flag so that the<br>
default remains to use nova-compute for these periodic tasks, but if you<br>
"opt in" they're done with a nova-periodic instead.<br>
<br>
Thoughts?<br>
<br>
Michael<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>