[occi-wg] OCCI MC - State Machine Diagram
Thijs Metsch
Thijs.Metsch at Sun.COM
Mon Apr 20 08:07:07 CDT 2009
I agree - this is fine with me.
On Mon, 2009-04-20 at 14:02 +0100, Edmonds, AndrewX wrote:
> Sounds like a good comprise J
>
>
>
> From: Sam Johnston [mailto:samj at samj.net]
> Sent: 20 April 2009 13:52
> To: Edmonds, AndrewX
> Cc: Thijs.Metsch at Sun.COM; occi-wg at ogf.org; Molino, VictorX M
> Subject: Re: [occi-wg] OCCI MC - State Machine Diagram
>
>
>
>
> 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.
>
>
>
>
>
> -------------------------------------------------------------
> 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.
--
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
More information about the occi-wg
mailing list