Re: [occi-wg] OCCI MC - State Machine Diagram
Sorry for the *very* late reply... Quoting [Michael Richardson] (Apr 20 2009):
"Andre" == Andre Merzky <andre@merzky.net> writes: Andre> For example, assume that I have a client which implements the Andre> core specification only, thus only knows the STOPPED, ACTIVE Andre> and SUSPENDED states (your original figure). What is that Andre> client supposed to do if the backend reports an PAUSED state?
How did it get to that state?
Since the client didn't put it into that state, it means that an operator or error must have forced this, so it's an error. Life does not always go as planned.
It is dangerous to assume that the client is the only legimitate entity which operates on the machine state diagram. The system admin, internal events, other clients, etc, may all have reason to trigger state changes, and this would not represent errors.
If the client does not do PAUSED state, the system shouldn't get into that state.
see above.
The client, upon seeing a state that it does not understand could attempt to recover by requesting a transition to primary state that it does understand.
If the client does not know the state, it cannot determine what a valid state transition would be.
Andre> BTW, I agree with Krishna's point that ENTRY and EXIT points Andre> are useful.
Where are they attached?
ENTRY point is attached to all states which can be reached initially, i.e. on creation. EXIT point is attached to all states which cannot be left, i.e. no transition exists to leave that state. Best, Andre. -- Nothing is ever easy.
Andre Merzky <andre@merzky.net> writes:
Quoting [Michael Richardson] (Apr 20 2009):
> "Andre" == Andre Merzky <andre@merzky.net> writes: Andre> For example, assume that I have a client which implements the Andre> core specification only, thus only knows the STOPPED, ACTIVE Andre> and SUSPENDED states (your original figure). What is that Andre> client supposed to do if the backend reports an PAUSED state?
How did it get to that state?
Since the client didn't put it into that state, it means that an operator or error must have forced this, so it's an error. Life does not always go as planned.
It is dangerous to assume that the client is the only legimitate entity which operates on the machine state diagram. The system admin, internal events, other clients, etc, may all have reason to trigger state changes, and this would not represent errors.
A concrete example: guests operating systems on our platform can already do an ACPI power down, terminating the running virtual machine. This is a state change which happens without an API call, but not an error state. Similarly, if a guest operating system suspends or hibernates in a way that's visible to the hypervisor (say ACPI S3/S4 sleep), a future version of our platform will probably transition the virtual machine process itself into a paused, suspended or dumped-to-disk state. Cheers, Chris.
participants (2)
-
Andre Merzky -
Chris Webb