[occi-wg] OCCI MC - State Machine Diagram
Tino Vazquez
tinova79 at gmail.com
Wed May 13 07:21:22 CDT 2009
Roger,
I quite like your approach (201 CREATED and 202 ACCEPTED), it helps
modeling the (now implicit) "pending" state (between Entry point and
Active) that I was worried about.
Also, the state history looks promising, but I am not quite sure how
we can order them (which state happen before which, or what happen
with duplicates). Am I missing something?
Regards,
-Tino
--
Constantino Vázquez, Grid Technology Engineer/Researcher:
http://www.dsa-research.org/tinova
DSA Research Group: http://dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
On Wed, May 13, 2009 at 1:06 PM, Roger Menday
<roger.menday at uk.fujitsu.com> wrote:
>
>
> 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. 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 ?
>
> 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.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
More information about the occi-wg
mailing list