[occi-wg] OCCI MC - State Machine Diagram

[Krishna Sankar (ksankar)]

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 at samj.net] 
Sent: Sunday, April 19, 2009 4:11 AM
To: Ignacio Martin Llorente
Cc: Krishna Sankar (ksankar); occi-wg at ogf.org
Subject: Re: [occi-wg] OCCI MC - State Machine Diagram

 

On Sun, Apr 19, 2009 at 12:16 PM, Ignacio Martin Llorente
<llorente at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090419/1da698f7/attachment.html