-
Notifications
You must be signed in to change notification settings - Fork 0
Instance_and_provider_states
- 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 createfailed if an error occurs.
* createfailed - 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#h3_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 a shutdown has been requested for the instance and is in
progress
* stopped
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.
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 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
- 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.
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 displayd in this case)