[occi-wg] OCCI MC - State Machine Diagram
Andre Merzky
andre at merzky.net
Wed May 13 07:52:03 CDT 2009
Roger,
Quoting [Roger Menday] (May 13 2009):
>
> Andre,
>
> I agree with your email. Your state diagram looks a simpler compared
> to the one on the wiki. And I believe your proposal is a lot closer to
> existing state modeling activities in the OGF (?)
>
> This might be an opportunity to express some concerns I have for the
> verb part of noun-attribute-verb. I see the various states as sub-
> resources (attached as a collection to the main resource). I can read
> the collection to discover the complete history of the resource
> (something which currently is not possible?). Furthermore, using both
> 201 CREATED and 202 ACCEPTED, I am able to distinguish between the
> resource currently in the process of moving to that state, and the
> resource already in that state.
Yes, that mechanism basically defines substates. Similar
would be ACTIVE:INITIALIZE and ACTIVE:COMPLETED etc. That would
allow to have a clean state model with a small number of
meaningful states
if ( state == 2xx )
if ( state == ACTIVE:* )
echo 'resource is active'
and would also allow to inform (human) clients about internal details
if ( state == *:COMPLETED )
echo 'transition to active completed'
There are several ways to express state details. It has
been noted before that BES defines one possible way to do
that, too.
> The resource publishes which states it
> can transition to at any point, (in this respect quite similar to the
> changing list of actuator URIs), but the state transition is triggered
> by creating a new resource in the states collection.
>
> Thoughts ?
I am not feeling comfortable with having a state model which
will change on the fly, depending what a resource will
answer. For one thing, it will make user interfaces and
tools really difficult to design:
- should I add a suspend button, even if it works only sometimes?
- if it worked once, will it work again?
- what can I do if it does not work? I want to suspend,
dammit! ;-)
Cheers, Andre.
>
> regards,
> Roger
>
> >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 (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:samj at samj.net]
> >>>Sent: 20 April 2009 13:52
> >>>To: Edmonds, AndrewX
> >>>Cc: Thijs.Metsch at Sun.COM; 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
> >>><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:Thijs.Metsch at Sun.COM]
> >>>Sent: 20 April 2009 13:42
> >>>To: Sam Johnston
> >>>Cc: Edmonds, AndrewX; 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
> >>>><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
> >>>
> >>>-------------------------------------------------------------
> >>>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-states.pdf>_______________________________________________
> >occi-wg mailing list
> >occi-wg at ogf.org
> >http://www.ogf.org/mailman/listinfo/occi-wg
>
>
> Roger Menday (PhD)
> <roger.menday at uk.fujitsu.com>
>
> Senior Researcher, Fujitsu Laboratories of Europe Limited
> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
> Tel: +44 (0) 208 606 4534
>
>
> ______________________________________________________________________
>
> Fujitsu Laboratories of Europe Limited
> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
> Registered No. 4153469
>
> This e-mail and any attachments are for the sole use of addressee(s) and
> may contain information which is privileged and confidential. Unauthorised
> use or copying for disclosure is strictly prohibited. The fact that this
> e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
> not guarantee that it has not been intercepted or amended nor that it is
> virus-free.
--
Nothing is ever easy.
More information about the occi-wg
mailing list