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. David
