[occi-wg] OCCI MC - State Machine Diagram

[Krishna Sankar (ksankar)]

Sam,

                Just for clarity, resources shouldn't enter the state
matrix at any point. For example they cannot enter the matrix in
Stopping stage or leave while in Active/Running state. That is why the
entry and exit points are important. But, of course, we will discuss
these in detail as we progress.

                Yep, a Pause state is required. Good catch.

Cheers

<k/>

 

From: Sam Johnston [mailto:samj at samj.net] 
Sent: Saturday, April 18, 2009 9:04 AM
To: Krishna Sankar (ksankar)
Cc: Chris Webb; occi-wg at ogf.org
Subject: Re: [occi-wg] OCCI MC - State Machine Diagram

 

Hi Krishna,

Thanks for the feedback.

On Sat, Apr 18, 2009 at 5:22 PM, Krishna Sankar (ksankar)
<ksankar at cisco.com> wrote:

 

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

Resources can enter or leave the matrix at any point (e.g. you can
import or migrate a suspended workload) so I think adding this, while
technically correct, might impair readability (as it does in the DMTF
diagram). The formal specification might want to include a formal state
diagram however. 

	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.

Sure, but it's really up to the provider as to whether they want to
implement these. Some workloads (e.g. slices) start atomically so the
transition doesn't make sense. We'll cater for the need but I'm a big
fan of giving implementors maximum flexibility.
 

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

Interesting idea - perhaps we'll include it in the registry as one of
those "optional" states. Another interesting one is "paused", where no
new requests will be accepted but all those in progress will be finished
- a load balancer shouldn't send any new requests but it shouldn't
terminate any existing ones either.
 

	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

Perhaps, but simpler systems might operate without billing or have a
simple meter based approach. If the infrastructure doesn't already
maintain information about stopped resources then we don't want to force
them to in order to implement the API.
 

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

Agreed. I don't think we should get too deep into this, but we should
bear in mind that the ability to see/compare costs in the clients
delivers huge value. I've included some simple metering examples to get
the creative juices flowing.

Sam

	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/c1471d81/attachment.html