[occi-wg] OCCI MC - State Machine Diagram
Andre Merzky
andre at merzky.net
Wed May 13 07:41:51 CDT 2009
Quoting [Sam Johnston] (May 13 2009):
>
> Andre,
> The diagram was previously simple enough to be comprehensible but the
> (IMO implicit) error transitions if anything detract from its meaning
> (again IMO). We are not in any position to lock this down as we simply
> don't know what a> implementors will want to do (some machines only
> ever really exist in a running state for example) and b> what
> tomorrow's machines will be capable of. That's why we have a registry
> and a todo item to review it in the context of interoperability.
Hi Sam,
sure, you don't kow what tomorrows system will do. But
doesn't that argument lead to a discussion about
extensibility, which is, IMHO, orthognal.
I may have missed some mails about the issue, my apologies
if the following has been discussed before:
The registry is one possible way to allow for extensibility
of the state model. But (a) it does not help to keep the
model clean (a cluttered registry is nothing you want you
clients to handle), and (b) I thought that for the OCCI
core, the set of states would be finite, and well defined.
Am I mistaken in (b)?
Thanks, Andre.
> Sam
>
> On Wed, May 13, 2009 at 12:09 PM, Andre Merzky <[1]andre at merzky.net>
> wrote:
>
> Hi all,
> I would like to follow up on the state model thread, even if
> people seem to have mostly agreed upon the version
> documented in the wiki
> ([2]http://forge.ogf.org/short/occi-wg/states)
> I am really unhappy with a number of things:
> - too many states
> - too many state transitions with no actions (i.e.
> methods) attached
> - unclear entry and exit points
> Please allow me to elaborate
> (1) Too many states:
> All the XXX-ING states (STARTING, SUSPENDING, RESUMING,
> STOPPING) seem to have no real benefit, apart from
> informing the client that a state transition is in
> progress. State transitions, however, should, IMHO, not be
> part of a state diagram, unless specific actions can be
> performed during that transition.
> For example the STOPPING state: there are no actions
> attached to that state, the client can do nothing but wait
> until the state reached STOPPED.
> So, why not going to STOPPED immediately, and adding the
> transition process to the semantics of the STOPPED state?
> (e.g., "resources can still be utilized iff they are
> required to store or retrieve the VM state").
> (2) Too many internal state transitions
> That is related to (1) of course: the diagram has 11
> internal state transitions (no actions attached), and 5
> external transitions (actions attached)....
> Well, that is not exactly incorrect or anything, but it is
> confusing matters. A state model should help to clarify
> what actions cause what state change.
> (3) unclear entry and exit points
> There is no state where the client can be sure that no
> remote resources are utilized anymore - i.e., an
> 'Destroyed' state is missing. At some point, a client
> needs to have the ability to free remote resources (well,
> unless one has garbage collection, but we don't want to go
> there, right?)
> STOPPED is not really the same - a STOPPED state can be
> moved to STARTING/ACTIVE via start(), so the backend cannot
> be allowed to free the resources.
> I do understand that the XXX-ING states are useful for
> informative purposes, for example, to allow a GUI to inform
> the user that a start() request has been received, and the
> backend is spinning up the machine. Those types of
> information can, however, easily provided by additional
> attributes, or sub-states.
> Attached is an alternate state diagram. It's main purpose
> is to illustrate that, by limiting the number of states and
> internal state transitions, one can derive a much simplier
> (and IMHO cleaner) state diagram.
> Cheers, Andre.
> PS.: Sorry for not using graffle. Sources are in xfig, so I
> don't attach them - don't want to get laughed at for using
> such ancient technology ;-)
> Quoting [Edmonds, AndrewX] (Apr 20 2009):
> >
> > Updated...
>
> >
> > -----Original Message-----
> >
> > 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:[3]samj at samj.net]
> > > Sent: 20 April 2009 13:52
> > > To: Edmonds, AndrewX
> > > Cc: Thijs.Metsch at Sun.COM; [4]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
> > > <[5]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:[6]Thijs.Metsch at Sun.COM]
> > > Sent: 20 April 2009 13:42
> > > To: Sam Johnston
> > > Cc: Edmonds, AndrewX; [7]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
> > > > <[8]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: [9]occi-wg-bounces at ogf.org
> > > [mailto:[10]occi-wg-bounces at ogf.org]
> > > > On Behalf Of Sam Johnston
> > > > Sent: 20 April 2009 11:56
> > > > To: Tino Vazquez
> > > > Cc: [11]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
> > > > <[12]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
> > > > [13]occi-wg at ogf.org
> > > > [14]http://www.ogf.org/mailman/listinfo/occi-wg
> > > --
> > > Thijs Metsch Tel: +49 (0)941 3075-122
> (x60122)
> > > [15]http://blogs.sun.com/intheclouds
> > > Software Engineer Grid Computing
> > > Sun Microsystems GmbH
> > > Dr.-Leo-Ritter-Str. 7 mailto:[16]thijs.metsch at sun.com
> > > D-93049 Regensburg [17]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.
--
Nothing is ever easy.
More information about the occi-wg
mailing list