[occi-wg] OCCI MC - State Machine Diagram

Krishna Sankar (ksankar) ksankar at cisco.com
Sat Apr 18 10:22:48 CDT 2009


Sam/Chris,

                Good work. Couple of points.

 

a)      The diagram needs a entry and exit point circles (actually
concentric circles) 

b)      The Stopping and Starting states are important. For example if
the state is Starting, clients could retry; schedulers could add the VM
in their pool et al. Stopping state will mean that the system is not
accepting service requests anymore. It might have to stay in this state
until all pending requests are completed.

c)       There is another state Aborting - don't know if we want to add
this.

d)      The stopped state, while not important during run time, will be
useful for account keeping, auditing et al. For example a log entry with
Stopped state with a timestamp

e)      Remember, monitoring and billing is an important plane for
Clouds and so we should also have states that are relevant from that
perspective ...

 

Cheers

<k/>

 

From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf
Of Sam Johnston
Sent: Saturday, April 18, 2009 6:14 AM
To: Chris Webb
Cc: occi-wg at ogf.org
Subject: Re: [occi-wg] OCCI MC - State Machine Diagram

 

On Sat, Apr 18, 2009 at 1:43 PM, Chris Webb
<chris.webb at elastichosts.com> wrote:

	Sam Johnston <samj at samj.net> writes:
	
	> I have created a diagram (attached) of what I think the
absolute minimum
	> core states need to be... essentially boiling them down to
"STOPPED" and
	> "ACTIVE" with "START" and "STOP" being the only requisite
actuators.
	> Transitional "STOPPING" and "STARTING" states are optional.

	+1
	
	I strongly agree with simplifying things in this way. Good
stuff!


I subsequently realised that in fact infrastructure like Amazon, Mosso
and ElasticHosts don't actually have a "stopped" state - "stop" for
these guys is more like "destroy".

It then occurred to me that there was no point making "stopped" optional
as if you don't need to start/stop/restart machines then you just don't
implement the machine control extension. It's far easier to create (HTTP
PUT) and then destroy (HTTP DELETE) a server than what it is to parse
the response to fire an actuator.

So basically the machine control extension becomes optional (but
possibly still interesting to indicate transitional states like
"starting" and "stopping" as Chris pointed out privately).

Sam

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


More information about the occi-wg mailing list