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