Background Jobs in conductor

Jan Provaznik jprovazn at redhat.com
Thu Dec 8 10:37:27 UTC 2011


On 12/01/2011 01:41 PM, Tomas Hrcka wrote:
> Hi all,
>
> the time has come, and we need to somehow implement background jobs. I
> am curently working on task which involve long run operations on
> provider side(ie. stop and delete). So I can make the UI not responding
> for 2-4 mins, but that is not what we want.
>

Hi,
it's only "destroy" operation which takes long time. This operation can 
be triggered on changing instance state to "stop". "stop" state is set 
by dbomatic which is running on background, so "destroy" operation 
should always run on background too -> no slow UI response in this case.

As I said before, we (will) need background job on conductor side anyway 
because of mass operations on instances, example: if a user selects 
multiple instances running on various providers, one of providers 
doesn't respond because of firewall/connection error, the conductor user 
will wait for a response forever or will get connection timeout error 
w/o knowing on which instance a command was executed. Another use case 
is "build+push" feature which we had to postpone - having background job 
solves this too.

> Question is what will we use for performing background jobs. On
> ruby-toolbox.com [1] is overview of ruby projects for background jobs.
> Or we can implement our own solution.
>
> [1] - https://www.ruby-toolbox.com/categories/Background_Jobs
>
>

Yes, there are many nice tools we can use. As it was already mentioned 
in this thread we have been using DelayedJob in conductor before and 
from what I remember it worked fine, but not saying we must use this again.

Another option is to extend dbomatic to do this job, but I don't think 
it's best solution.

Since this background job integration probably won't be part of 1.0 
version we have enough time to think about best solution.

Jan



More information about the aeolus-devel mailing list