Sounds like a good comprise J
From: Sam Johnston [mailto:samj@samj.net]
Sent: 20 April 2009 13:52
To: Edmonds, AndrewX
Cc: Thijs.Metsch@Sun.COM; occi-wg@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@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@Sun.COM [mailto:Thijs.Metsch@Sun.COM]
Sent: 20 April 2009 13:42
To: Sam Johnston
Cc: Edmonds, AndrewX; occi-wg@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@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@ogf.org
[mailto:occi-wg-bounces@ogf.org]
> On Behalf Of Sam Johnston
> Sent: 20 April 2009 11:56
> To: Tino Vazquez
> Cc: occi-wg@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@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@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@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.