Same logic applies to stop and suspend as well ;o) I think the stop and suspend could be semantically the same except make be how state is handled.

Is the difference that stop erases all internal state while suspend maintains the state ? But that is the RESTART and RESUME actions, not the STOP/SUSPEND itself. One could RESUME after STOP, couldn’t one ?

I also think pending state after entry is a good idea. To be correct, as Ignacio mentions, a VM has to have a pending or resuming state before becoming active. Same for exit. Exit out after stopping or suspending.

Cheers

<k/>

From: Sam Johnston [mailto:samj@samj.net]
Sent: Sunday, April 19, 2009 4:11 AM
To: Ignacio Martin Llorente
Cc: Krishna Sankar (ksankar); occi-wg@ogf.org
Subject: Re: [occi-wg] OCCI MC - State Machine Diagram

On Sun, Apr 19, 2009 at 12:16 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es> wrote:

I am not sure what is the state of this discussion, but I would like to support the addition of ENTRY and EXIT points to the diagram.

Done. Attached, along with OmniGraffle source.

Moreover, if we do not assume that the submitted VMs have to run immediately or not at all,  I would like to suggest that we need a "Pending" state in the diagram. The new submitted VMs remain in this state until there are resources available. That could be the "DEFINED" state or the DMTF "INITIAL" state.

"Pending" is ambiguous. "Resuming" is pending, so is "suspending". There's various takes on "defined" and "initial" too... for example if you were to implement something like the Q-Layer^WSun Cloud API web interface on top of OCCI then you would likely start by creating and linking a bunch of objects, none of which would be useful until associated with actual resources - it would be like a shell/skeleton.

Perhaps this is something worth taking into consideration, though as I'd rather not impose too much on implementors it probably belongs in the registry.

Sam