[rm-wg] [occi-wg] OCCI MC - State Machine Diagram

[alexis.richardson at gmail.com]

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/rm-wg/attachments/20090418/cfd6f6bf/attachment.html