Updated... -----Original Message----- From: Thijs.Metsch@Sun.COM [mailto:Thijs.Metsch@Sun.COM] Sent: 20 April 2009 14:07 To: Edmonds, AndrewX Cc: Sam Johnston; occi-wg@ogf.org; Molino, VictorX M Subject: RE: [occi-wg] OCCI MC - State Machine Diagram 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@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. -- 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.
