[occi-wg] OCCI MC - State Machine Diagram

Sam Johnston samj at samj.net
Mon Apr 20 07:52:29 CDT 2009


I'd tend to side with Thijs on this one - having a complete state machine is
a lot less important when the implementation can tell its clients what the
next states are (and the humans what they mean in plain $LANGUAGE). That
said, if you want to add a dotted loop back to the start then that might
help the perfectionists sleep easy.

Sam

On Mon, Apr 20, 2009 at 2:47 PM, Edmonds, AndrewX <andrewx.edmonds at intel.com
> wrote:

> Then conceptually, how do we recover from an error state if we've exited?
> Also if we want to support error state recovery, should the state model
> reflect this?
>
> -----Original Message-----
> From: Thijs.Metsch at Sun.COM [mailto:Thijs.Metsch at Sun.COM]
> Sent: 20 April 2009 13:42
> To: Sam Johnston
> Cc: Edmonds, AndrewX; occi-wg at ogf.org; Molino, VictorX M
> Subject: Re: [occi-wg] OCCI MC - State Machine Diagram
>
> As I stated before maybe we an add another exit-point instead of a real
> state.
>
> Cheers,
>
> -Thijs
>
>
> On Mon, 2009-04-20 at 14:39 +0200, Sam Johnston wrote:
> > On Mon, Apr 20, 2009 at 2:29 PM, Edmonds, AndrewX
> > <andrewx.edmonds at intel.com> wrote:
> >         I updated the state model (attached) to include an error
> >         state. Couldn’t see how to delete attachments so maybe someone
> >         here has better luck? I also began to add identifiers to each
> >         process transition but the diagram started to become cluttered
> >         so left them out.
> >
> >
> > I would suggest that it's better to keep this clean (though I'm
> > impressed that you got as far as you did!). You can reach an error
> > state from anywhere - if a machine is found to be corrupt even while
> > stopped then a STOPPED->ERROR transition makes sense for example.
> >
> > Sam
> >
> >         From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org]
> >         On Behalf Of Sam Johnston
> >         Sent: 20 April 2009 11:56
> >         To: Tino Vazquez
> >         Cc: occi-wg at ogf.org; Molino, VictorX M; Thijs Metsch
> >
> >
> >         Subject: Re: [occi-wg] OCCI MC - State Machine Diagram
> >
> >
> >         Hi Tino,
> >
> >
> >
> >
> >         A lot of this is covered in the state registry (which I'll
> >         copy below for you) but comments inline nonetheless.
> >
> >         On Mon, Apr 20, 2009 at 12:35 PM, Tino Vazquez
> >         <tinova at fdi.ucm.es> wrote:
> >
> >         Howdy everyone,
> >
> >         Excellent thread. My three cents:
> >
> >         1) I think we should define clearly the semantics of the
> >         states. for
> >         instance, what is the difference between STOPPED and
> >         SUSPENDED? Is it
> >         that with SUSPENDED the state is saved and not with STOPPED?
> >
> >
> >         Yes, it's exactly that. From the state registry: STOPPED =
> >         "The resource is inactive and has no saved state" and
> >         SUSPENDED="The resource is inactive and has saved state"
> >
> >
> >
> >                 2) I really think we need an entry state like
> >                 "PENDING" or "DEFINED".
> >                 It will help in implementation relying on a
> >                 best-effort scheduler to
> >                 match VMs and hosts, like EC2 does. This will be the
> >                 state where
> >                 machines will wait for a host to be available to run
> >                 on. Also, I don't
> >                 really think that a machine entering its life cycle in
> >                 SUSPENDED state
> >                 is a good idea.
> >
> >
> >         I tend to agree, but I'd like the terminology to be completely
> >         unambiguous... something like "NEW" [for this AS].
> >
> >
> >
> >                 3) +1 to the "CRASHED", "ERROR" or "FAILED" state.
> >
> >
> >         ABORT[ING|ED] = "The resource encountered an error and is
> >         aborting/has aborted".
> >
> >
> >                 What do you think?
> >
> >
> >         Some of these transitions take a while so some way of
> >         indicating progress (especially interesting for long tasks
> >         like live migrations) would be useful. Would prefer a
> >         mechanism that worked universally for the API.
> >
> >         Sam
> >
> >
> >
> >
> >         Extensions
> >         State control
> >                State
> >
> >
> >             Transitions
> >
> >
> >             Description
> >
> >
> >         aborting
> >
> >
> >         aborted
> >
> >
> >         The resource
> >         encountered an error
> >         and is aborting
> >
> >
> >         aborted
> >
> >
> >         n/a
> >
> >
> >         The resource
> >         encountered an error
> >         and has aborted
> >
> >
> >         active
> >
> >
> >         pause, restart,
> >         stop, suspend
> >
> >
> >         The resource is
> >         active
> >
> >
> >         resuming
> >
> >
> >         aborting, active
> >
> >
> >         The resource is
> >         becoming active and
> >         restoring state
> >
> >
> >         pausing
> >
> >
> >         aborting, paused
> >
> >
> >         The resource is
> >         preparing to refuse
> >         new requests
> >
> >
> >         paused
> >
> >
> >         aborting, resume
> >
> >
> >         The resource is
> >         refusing new
> >         requests
> >
> >
> >         starting
> >
> >
> >         aborting, active
> >
> >
> >         The resource is
> >         becoming active
> >
> >
> >         stopped
> >
> >
> >         start
> >
> >
> >         The resource is
> >         inactive and has no
> >         saved state
> >
> >
> >         stopping
> >
> >
> >         stopped, aborting
> >
> >
> >         The resource is
> >         becoming inactive
> >         and destroying state
> >
> >
> >         suspended
> >
> >
> >         resume, stop
> >
> >
> >         The resource is
> >         inactive and has
> >         saved state
> >
> >
> >
> >         Note: Stable states and user transitions in bold.
> >
> >
> >
> >
> >         -------------------------------------------------------------
> >         Intel Ireland Limited (Branch)
> >         Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> >         Registered Number: E902934
> >
> >         This e-mail and any attachments may contain confidential material
> for
> >         the sole use of the intended recipient(s). Any review or
> distribution
> >         by others is strictly prohibited. If you are not the intended
> >         recipient, please contact the sender and delete all copies.
> >
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> --
> Thijs Metsch                        Tel: +49 (0)941 3075-122 (x60122)
> http://blogs.sun.com/intheclouds
> Software Engineer Grid Computing
> Sun Microsystems GmbH
> Dr.-Leo-Ritter-Str. 7               mailto:thijs.metsch at sun.com
> D-93049 Regensburg                  http://www.sun.com
>
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090420/276eca23/attachment.html 


More information about the occi-wg mailing list