[occi-wg] OCCI MC - State Machine Diagram

[Sam Johnston]

I've added both to the registry:

http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Registries

Sam

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

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