RFC feature planning - robust instance launching

Jan Provaznik jprovazn at redhat.com
Tue Apr 3 10:57:52 UTC 2012


On 03/27/2012 02:32 PM, Jan Provaznik wrote:
> Hi, sending proposal for "robust instance launching" scenario. Any
> thoughts or improvement ideas are welcomed.
>
> Cut&paste from
> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Robust_instance_launching
>

Hi, thanks for feedback, I've updated the wiki page. The page is quite 
long so I will not paste the whole text here again but feel free to 
quote and comment any part here.

Major update is using a background job tool:

Background job
Will be used for launching instances. Even sending launch requests for a 
multi-instance deployment has following disadvantages:
may take a long time, "connection timeout" error may be displayed
user is blocked for this time, he sees only "loading" cursor
we can't inform a user about a launch progress/what's being done
There are plenty background job tools for ruby/rails. Choosing suitable 
one is a task of this scenario. I would like to push it a little bit 
further:
dbomatic daemon might be replaced by this bg job tool. There is no 
reason to keep 2 things which does similar thing.

I briefly searched what are mostly used tools and here are 2 examples:
1. Delayed Job:
   pros: we used this before, it worked fine, it's packaged in fedora
   cons: doesn't support recurring jobs: 
https://github.com/collectiveidea/delayed_job/wiki/FEATURE:-Adding-Recurring-Job-Support-to-Delayed_Job 
Though workaround is re-enqueue the job everytime it's executed

2. Resque Scheduler:
   pros: supports both recurring and single jobs, seems to work fine 
(done only brief experiments)
   cons: not packaged in fedora, dependency on external service (redis)


Not saying we have to use one of above, it's just an inspiration. But 
I'd prefer a bg tool which supports recurring jobs "natively" so it 
could be dbomatic replacement.

Jan



More information about the aeolus-devel mailing list