<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Possibly then this could work out by creating a specific class that is started by nova-compute as a 'helper' process where all of these periodic actions happen.</div><div><br></div><div>Using the multiprocessing library could be the way to tie these together (using a daemonized subprocess), but not using the queue to interchange anything (unless needed).</div><div><br></div><div>Then when nova-compute fires up, it can fire up its 'helper' process that does background tasks that nova-compute 'likes' but will not block nova-compute from running. This 'helper' process has the benefit that it will be killed when nova-compute is killed and/or stopped (due to the mentioned daemoinizing), they are somewhat tied together (and easier to find who created who), and there doesn't need to be YAS (yet another process/service) to remember to start.</div><div><br></div><div>An idea at least :-P</div><div><br></div><div>-josh</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Yun Mao <<a href="mailto:yunmao@gmail.com">yunmao@gmail.com</a>><br><span style="font-weight:bold">Reply-To: </span> OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Date: </span> Monday, November 19, 2012 7:30 PM<br><span style="font-weight:bold">To: </span> OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [openstack-dev] A new nova service? nova-periodic?<br></div><div><br></div><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div>
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></div></div></span></body></html>