[occi-wg] OCCI MC - State Machine Diagram
alexis.richardson at gmail.com
alexis.richardson at gmail.com
Sat Apr 18 17:09:24 CDT 2009
As far as I can tell -- Commissioning appears to consist of the marshalling
of components of a larger whole, before work can commence. I'm not sure if
we need that (cf. my comment about operands in last email, below).
On Apr 18, 2009 10:57pm, Sam Johnston <samj at samj.net> wrote:
> Evening,
> I've trawled through this document (ref model from it attached for
> convenience) and am not sure that it (and others like it for that matter)
> give the flexibility our implementors are going to need. It's early days
> to be standardising and even if it weren't then trying to foist a fixed
> lifecycle on people is either a> not going to work or b> limit them
> unnecessarily.
> Specific issues include the entry/exit points (live migrations start
> active for example and in some systems active is the only valid state),
> terminology (abstraction is fine but I had to hit the dictionary to
> confirm that "extant" meant what I thought it meant), and the requirement
> for a commissioning step is still unclear to me (though it will be soon
> when we start looking at templates).
> That said I'd happily work with you guys to bring our model into line
> with your or vice versa.
> Cheers,
> Sam
> On Sat, Apr 18, 2009 at 10:12 PM, Alexis Richardson
> alexis.richardson at gmail.com> wrote:
> David,
> One of our side goals is to explain the relationship between whatever
> simple OCCI lifecyle we settle on, and the OVF lifecyle. Can you tell
> us if the OGF RM group has cross checked the RM states and transitions
> against OVF?
> BTW ... one simplifying assumption for OCCI *may* be that API operands
> are single slices (VMs).
> alexis
> On Sat, Apr 18, 2009 at 8:40 PM, David Snelling
> David.Snelling at uk.fujitsu.com> wrote:
> > Folks,
> > I write this note as a fellow OGF working group chair. In the Reference
> > Model working group we have been working toward a Reference Model, which
> > includes a life cycle state model. Please have a look at the sections in
> > our draft document that pertain to life cycle and see if you can map
> your
> > states sensibly onto/into these.
> > The idea is that your states, which map directly, are aliases for those
> in
> > the Reference Model. Any of yours that don't map directly, should be
> > sub-states of one from the reference model.
> > If this is not possible, please let us know. Ours is a work in
> progress, so
> > it is possible that there are faults in our model.
> > Please come talk to us at OGF26.
> > See: http://forge.gridforum.org/sf/go/doc14766?nav=1
> >
> > On 18 Apr 2009, at 12:40, Sam Johnston wrote:
> >
> > Afternoon all,
> >
> > I have created a diagram (attached) of what I think the absolute minimum
> > core states need to be... essentially boiling them down to "STOPPED" and
> > "ACTIVE" with "START" and "STOP" being the only requisite actuators.
> > Transitional "STOPPING" and "STARTING" states are optional.
> >
> > I believe states should be completely unambiguous so I don't
> particularly
> > like the DMTF model ("stopped" and "active" machines are also "defined"
> but
> > this is a separate state) and that also rules out vague terminology like
> > "inactive" (which could mean both "stopped" and "suspended").
> >
> > I've got an optional RESTART actuator which takes you from "ACTIVE" to
> > "STARTING" as well as an optional "SUSPEND" and "RESUME" cycle which
> takes
> > you via the transitional "SUSPENDING" and "RESUMING" states
> between "ACTIVE"
> > and "SUSPENDED".
> >
> > DMTF have another "paused' state but I wonder whether this needs to be a
> > state in its own right or if it's an attribute of "suspended". That's a
> > rhetorical question - we could spend all week discussing nuances but
> for now
> > I want to make sure we agree on the absolutely minimalist core
> > functionality. Other states can be added via a live registry which we
> can
> > pre-populate with a view to guiding innovation without stifling it.
> >
> > This has been uploaded to the wiki:
> >
> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/StateModel
> >
> > Sam
> >
> >
> > Machine.svg>_______________________________________________
> > occi-wg mailing list
> > occi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> >
> > Take care:
> > Dr. David Snelling
> > Fujitsu Laboratories of Europe Limited
> > Hayes Park Central
> > Hayes End Road
> > Hayes, Middlesex UB4 8FE
> > Reg. No. 4153469
> > +44-7590-293439 (Mobile)
> >
> >
> >
> > ______________________________________________________________________
> >
> > 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
> >
> >
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090418/cfd6f6bf/attachment.html
More information about the occi-wg
mailing list