Instance and Provider States

Instance and provider states

General Info

Instance states in Conductor

• new - used only when the instance’s object is created in DB when creating  a deployment. When the instance is being launched, this state is changed to a state returned by dc-api (typically pending or running) or to create_failed if an error occurs.
• create_failed - this state can be set only if the instance can’t be launched because of an error on conductor side and when instance create request wasn’t sent to dc-api yet
• error - this state is probably obsolete and is not used anymore
• vanished - is set by dbomatic when instance’s state is being checked and the instance is not found on provider’s side for some reason. Note: at the moment, vanished state is set also when dc-api for this instances is not accessible - this is probably bug, we could use some other state (unknown) to distinguish between inaccessible provider and disappeared instance.

Following states are same as in deltacloud api - doc: http://deltacloud.apache.org/api.html#4

• pending - creation of the instance has been requested and is in progress
• running - the instance is running
• shutting_down - a shutdown has been requested for the instance and is in progress
• stopped - a shutdown has been requested for the instance and is in progress

Important: state transitions differ for various cloud types. For example an instance in pending state passes to running state for EC2, but for RHEVM it passes to state stopped and a user has to send start action explicitly.

Stateful instances

At the moment, Conductor doesn’t support stateful instances (IOW it considers all instances to be stateless).  So for now we don’t have special state to distinguish between stopped and destroyed instances (this is going to be changed soon). Dc-api supports stateful instances and uses finish state to represent instances which were stopped and don’t exist anymore.

Provider states

Provider has two attributes which have an effect on instance launching:

• enabled (true|false) attribute - this can be set by a user, instances can be launched only on enabled providers
• available (true|false) attribute - this attribute is set when dc-api for specified provider becomes inaccessible. Dbomatic periodically checks both provider and realms availability and sets this attribute

What happens with instances on various provider events

• provider is disabled: all pending and running instances are stopped, new instances can’t be launched on this provider.
• provider is enabled: state of any existing instances is unchanged, new instances can be launched on this provider. To enable a provider, this provider must be accessible.
• provider becomes inaccessible: state of all active instances (pending, running, shutting down)  is set to vanished by dbomatic. Dbomatic continues in periodic check of state of these instances.
• provider becomes accessible again: state of all instances marked before as vanished is set back to their real state.
• inaccessible provider is disabled: in this case all active states are vanished when provider is being disabled, so instances are not stopped on disable action. Then when the disabled provider becomes accessible again, instances are set back to their real state. This is not consistent with disabling a provider which is accessible because instances are stopped in that case.

Instance terminate option

If dc-api is not accessible and a user tries to stop an instance or disable a provider, the  user has an option to terminate such instance

• instance’s state is set to stopped in Conductor w/o doing any provider-side action, IOW stopped state doesn’t reflect real provider-side state. Reason for this feature is to be able to get rid of instances if dc-api suddenly goes away forever. Because dbomatic now sets vanished state for inacessible instances, there is very small chance that a user would get this dialog (dbomatic checks are done every minute), so it’s almost useless.

Question is what we expect from disabling a provider? Is it just not allowing launching of new instances on this provider? If yes, then setting vanished state when a provider becomes inaccessible seems to be quite OK (although different state than vanished should be used in this case). But if we want to have all instances stopped when disabling a provider, then setting vanished state for inaccessible instances is not best idea, because they can always become active again.

maybe combination of this would work:

• disabling means just not allowing launching new instances
• when a provider becomes inaccessible, instances are set as not accessible or unknown (so this state is distinguished from vanished state which should be used only if instances is not found on provider side)
• not accessible instances are allowed to delete (warning should be displayed in this case)