RFC feature planning - robust instance launching

Richard Su rwsu at redhat.com
Wed Apr 4 00:41:59 UTC 2012


On 03/27/2012 05:32 AM, Jan Provaznik wrote:
>
> 3)launch instances on state change: instances which have not been 
> launched in phase 2. because they depend on instanceX are launched 
> when instanceX is running. This can be done from instance after_update 
> callback - when instance’s state is changed to ‘running’, get list of 
> instances which becomes unblocked and launch them. Phase 3 will be 
> usually executed on background, because instances states are usually 
> updated by dbomatic (though not always - in some cases instance’s 
> state is updated directly on dc-api request call).
> If an instance launch fails for some reason, we try to deploy 
> somewhere else: stop all instances which have been already launched, 
> then find another match (skipping all matches which failed), reset 
> state to NEW for all instances (or drop and recreate them)
>
> launch progress page (TBD)
> Angus suggested that there could be something like “launch progress 
> page” where details of what’s being done w/ deployment would be 
> showed. So if the user checks “show me details” checkbox before 
> clicking “launch” button, he is redirected to this progress page where 
> info which step is being done is displayed:
> "Selecting provider account... account_name"
> “Making launch request for instance... x”
>
> This could be probably just displaying of all events associated with 
> this deployment.
> Showing of this page would be optional, alternatively it could be part 
> of deployment’s show page where a user could redirected after launch.
>
>
> High-level implementation details
> Add 'state' attribute to Deployment model, states can be:
> new - deployment is created in Conductor DB, but no instance has been 
> launched yet
> pending - at least one instance launch has been requested
> failed - final state, deployment launch/shutdown failed
> rollback_in_progress - an error occurred during launching an instance 
> and there are already some launched instances which have to be stopped
> rollback_failed - stopping of already launched instances failed
> rollback_complete - stopping of already launched instances, now the 
> deployment can be launched somewhere else
> running - all instances were successfully are in running state
> shutting_down - sthutdown was initiated
> stopped - all instances are stopped
>
> Allowed state transitions:
> new -> pending
> pending -> running|rollback_in_progress|failed
> rollback_in_progress -> rollback_complete|rollback_failed
> rollback_complete -> pending|failed
> running -> shutting_down
> shutting_down -> stopped
>
> Deployment state will be used to track deployment's history and decide 
> what to do on a change - for example if last deployment's instance is 
> stopped, deployment relaunch is done only if deployment was in 
> rollback_in_progress state, otherwise the deployment stays stopped.

Hi Jan,

The state transition is different for RHEV. When instances are created 
it goes from NEW -> PENDING -> STOPPED.

dbomatic then starts the RHEV instance if it sees current state is 
STOPPED and total RUNNING state time is 0.



More information about the aeolus-devel mailing list