[occi-wg] OCCI MC - State Machine Diagram

[Sam Johnston]

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