[occi-wg] OCCI MC - State Machine Diagram

[Sam Johnston]

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<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Registries>(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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090420/52d48612/attachment.html