[occi-wg] OCCI MC - State Machine Diagram

[Thijs Metsch]

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