Cloud State component

Jan Provaznik jprovazn at redhat.com
Mon May 14 08:11:16 UTC 2012


On 05/12/2012 01:59 AM, Richard Su wrote:
> On 05/11/2012 04:27 AM, Jan Provazník wrote:
>> Hi,
>> there is a new proposal described here:
>> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Cloud_State
>>
>> Any ideas/thoughts/feedback would be appreciated.
>>
>> Jan
>
> Jan
>
> I like the idea of separating the instance status checking and updates
> out of conductor main and breaking up the code along functional lines.
>
> I have a couple of questions:
>
> 1.
> Does the engine periodically poll for instance state? I assume yes. Or
> is it through some other mechanism to be determined.
>

Yes, the engine would use polling for status checking.

I think most of the plan about integrating delayed_job and use it for 
dbomatic functionality stays same, except that we might do this in the 
engine.

> 2.
> Assuming new engine is integrated into conductor, what happens if the
> application is restarted? Are instance updates atomic between conductor
> and the engine? Imagine a scenario where conductor and engine has state
> A for an instance. The engine polls the instance and now sees state B
> and saves it to the database to its own model. The app is then restarted
> before the callback to conductor is made. Engine polls instance again
> and sees state B matching what's in the database, so no callback is
> made, and conductor continues to reflect state as A.
>

Good point, I was thinking that for first iteration (the engine is part 
of conductor) callbacks might be part of save transaction when updating 
state in engine, IOW all callbacks are called from engine's 
CloudStateInstance before_save callback - if a callback fails, state is 
not updated both in engine and conductor. Then whole state update is 
tried again on next status check.

> We can say that the first status update by the engine is always called
> back to conductor. The engine would need to be smart enough to know if
> the update is the first since it started up.
>
> Having the engine not integrated into conductor and having it run as its
> own service would make this more tricky.
>

Agree. We might need to add another table which keeps track what 
callbacks haven't been called yet for each instance.

> - Richard
>

Jan



More information about the aeolus-devel mailing list