Hi Tino,
A lot of this is covered in the state registry (which I'll copy below for you) but comments inline nonetheless.
Howdy everyone,
Excellent thread. My three cents:
1) I think we should define clearly the semantics of the states. for
instance, what is the difference between STOPPED and SUSPENDED? Is it
that with SUSPENDED the state is saved and not with STOPPED?
2) I really think we need an entry state like "PENDING" or "DEFINED".
It will help in implementation relying on a best-effort scheduler to
match VMs and hosts, like EC2 does. This will be the state where
machines will wait for a host to be available to run on. Also, I don't
really think that a machine entering its life cycle in SUSPENDED state
is a good idea.
3) +1 to the "CRASHED", "ERROR" or "FAILED" state.
What do you think?
State | Transitions | Description |
---|---|---|
aborting | aborted | The resource encountered an error and is aborting |
aborted | n/a | The resource encountered an error and has aborted |
active | pause, restart, stop, suspend | The resource is active |
resuming | aborting, active | The resource is becoming active and restoring state |
pausing | aborting, paused | The resource is preparing to refuse new requests |
paused | aborting, resume | The resource is refusing new requests |
starting | aborting, active | The resource is becoming active |
stopped | start | The resource is inactive and has no saved state |
stopping | stopped, aborting | The resource is becoming inactive and destroying state |
suspended | resume, stop | The resource is inactive and has saved state |
Note: Stable states and user transitions in bold.