Open Stack

On Tue, Jan 15, 2013 at 07:59:38AM +1100, Michael Still wrote:
> On Mon, Jan 14, 2013 at 10:39 PM, Mark McLoughlin <markmc at redhat.com> wrote:
> 
> > Or perhaps even simpler than native threads, have the periodic task
> > spawn off a new process for the long-running operation and reap it on
> > the next task iteration.
> 
> This is an interesting approach. It is however harder for the
> developer adding a periodic task to implement, which means they're
> more likely to get it wrong.
> 
> I find the simplicity of being able to just mark a periodic task as
> being external very attractive. Its "no" additional code for the
> person making something external, its a mechanism that developers are
> already familiar with, and it keeps the code for the periodic element
> with the rest of the code for that functionality. In the same way that
> a developer doesn't have to worry about the internal mechanisms of how
> periodic tasks get run, I would like to have something where the
> majority of developers don't have to spend significant time
> implementing a new mechanism for just their periodic task, and then
> adding tests for that mechanism.
> 
> I can see a few approaches now:
> 
>  - we keep nova-periodic as a separate process: simpler to code,
> harder to deploy
> 
>  - we move the existing nova-periodic code into a separate process
> fork()ed by nova-compute on startup: separates out slow periodic tasks
> from the main nova-compute, easier to deploy. One very slow periodic
> task still blocks other less slow periodic tasks.
> 
>  - we change the periodic task running code to fork() a process every
> time it needs to run an "external" periodic task, it then wait()s for
> those processes later in its loop: means you can have as many slow
> periodic tasks as you want without them blocking each other, makes the
> periodic task running more complex and therefore more likely to have
> bugs, easy to deploy, transparent to users.
> 
> What do people think?

I think the last option is the only viable one, because if we allow
one slow periodic task to block other periodic tasks, we've not really
solved the problem, merely moved it somewhere else.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|