[occi-wg] OCCI MC - State Machine Diagram
Andre Merzky
andre at merzky.net
Wed May 13 07:53:00 CDT 2009
Quoting [Alexis Richardson] (May 13 2009):
>
> Andre
>
> I (personally) would certainly agree with (b) **** for the draft ****
> so that people can start implementing and prototyping, thus creating a
> feedback loop so that we can go from draft to review to final.
Sure, I fully understand that. Then please consider my
comments to apply for the final design, and feel free to
shelf them for the time being... :)
Best, Andre.
> alexis
>
>
>
>
>
> On Wed, May 13, 2009 at 1:41 PM, Andre Merzky <andre at merzky.net> wrote:
> > 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.
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> >
--
Nothing is ever easy.
More information about the occi-wg
mailing list