deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Re: [PATCH] Canonicalize instance states.
Date Fri, 10 Sep 2010 23:44:09 GMT
On Thu, 2010-09-09 at 15:30 -0400, Chris Lalancette wrote:
> For some drivers, we were passing the raw string we got from
> the cloud provider through as the instance state.  However,
> that doesn't fit in with trying to make the drivers act consistent,
> so make sure all of the drivers have a translation layer between
> the cloud provider's states and the deltcloud API states.

ACK to the patch; stylistically, it would be more rubyish if states were
symbols internally, but that'll be a battle for another day.

>   After
> this series, there are only 3 valid deltacloud states: "RUNNING",
> "STOPPED", and "PENDING".  We may want to think about adding
> additional states in the future, but these cover most of the
> current use-cases.

After not getting anywhere with writing this down, I took all the state
machines from existing drivers and put them into a PDF (attached).

The only other state that seems important is 'Shutting_down' (e.g., RAX
and Rimu)

There are also plenty of errors in the state machines: e.g., EC2 has a
Shutting_down state, but it's impossible to get to; RHEV-M transitions
from pending to shutting_down on create.

To catch such errors, I wonder if it would be worth to try and define
the overall (nondeterministic) Deltacloud state machine and require that
drivers use a subset of it. Besides allowing to catch silly errors like
the above, it would also serve as documentation for users of the API
what could possibly happen from a driver.


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message