On 04/04/2012 02:41 AM, Richard Su wrote:
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.
yes, though the above states are for deployment (not instance)