[occi-wg] OCCI MC - State Machine Diagram
Alexis Richardson
alexis.richardson at gmail.com
Wed May 13 07:44:11 CDT 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.
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
>
More information about the occi-wg
mailing list