On Sat, Apr 18, 2009 at 5:22 PM, Krishna Sankar (ksankar) <ksankar@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston
Sent: Saturday, April 18, 2009 6:14 AM
To: Chris Webb
Cc: occi-wg@ogf.org
Subject: Re: [occi-wg] OCCI MC - State Machine Diagram

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

Sam Johnston <samj@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