RFC: Dbomatic testability and performance

Mo Morsi mmorsi at redhat.com
Thu Apr 5 10:02:29 UTC 2012


>>>>
>>>> Sooner today I proposed in thread "RFC feature planning - robust
>>>> instance launching" to replace dbomatic with a background job tool
>>>> which supports both delayed and recurring jobs:
>>>> - delayed jobs would be used for launching instances
>>>> - recurring jobs would be used for all stuff done by dbomatic
>>>>
>>>> The code in "check_one_account" method could be part of
>>>> ProviderAccount model, so it can be covered by common rspec tests
>>>> we have.
>>>> The rest of script is just about parsing params, and forking
>>>> processes in an interval - we get all this logic for free when
>>>> using a bg job tool.
>>>>
>>>> Jan
>>>
>>> Thanks for the feedback Jan. I like the idea of replacing dbomatic
>>> with a background job tool. Placing a task on a queue to launch an
>>> instance is much better approach to having dbomatic poll in the
>>> background. It also eliminates the dbomatic timeout issues when
>>> launching a large number of instances.
>>>
>>> As for the instance status checks, do we need recurring jobs at all?
>>> I wonder if we can simply create a delayed_job that runs and then
>>> queues itself again upon completion.
>>>
>>>
>> Would requiring all recurring jobs to re-scedule the next iteration
>> be less reliable than making sure the job scheduler component can
>> handle recurring jobs natively? We could get around that a bit by
>> making sure wrap the whole job impl with a "rescue everything" block
>> which queues the next iteration no matter what. What do other
>> rails-based projects do about recurring background jobs?
>>
>> Scott
>>
>
> I have to say, I don't immediately like the idea of having the job
> need to reschedule itself. It feels error-prone and tightly coupled to
> me.

Agreed, if a task gets interrupted and lost (someone pulls the plug on a
machine) it will be so forever.



> I also strongly feel a full task/feature/whatever is needed here
> to:
> * list out what we would actually use such a daemon for, intial
>   candidates off the top of my head include everything currently in
>   dbomatic plus ldap user/group syncing, though I am sure there are
>   others.

Did we ever take care of handling instance actions that get invoked
outside the scope of Aeolus? Eg if an instance is started on a cloud
provider can we detect it? Can see an external tool (eg outside of
conductor, such as dbomatic) being useful in this sort of situation.

  -Mo




More information about the aeolus-devel mailing list