[occi-wg] Fwd: Re: [Fwd: Simplified OCCI VM lifecycle diagram]

[Sam Johnston]

On Mon, Feb 22, 2010 at 3:02 AM, Gary Mazz <garymazzaferro at gmail.com> wrote:

> Didn't we talk about this at one time ?? It seems like a lifetime ago :)
>  The one on the wiki was too visually "busy". The simplified one was
> intended to look more...  simple.
>

Without all the traces back to "Error" (which should be implicit - errors
can come at any time) the one on the wiki is plenty simple enough - as is
yours. The thing with state diagrams (like cloud APIs) is that they're like
a$$holes - everybody's got one - and they all vary in sufficiently important
ways as to be completely incompatible with each other. Furthermore, we lack
the ability to predict the future so it needs to be fully extensible.

Sam (who has better things to be doing at 3am on a Monday than
re-re-rehashing old arguments)

 Edmonds, AndrewX wrote:
> > FYI: we did also have this on our wiki, with the very same states as in
> Gary's diagram.
> >
> >
> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/StateModel
> >
> > KIS, LCD,
> >
> > Andy
> >
> > -----Original Message-----
> > From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf
> Of Gary Mazz
> > Sent: Sunday, February 21, 2010 11:04 PM
> > To: Alexis Richardson
> > Cc: occi-wg at ogf.org
> > Subject: Re: [occi-wg] Fwd: Re: [Fwd: Simplified OCCI VM lifecycle
> diagram]
> >
> > Alexis,
> >
> > Both Sam and I have run into instances where not all providers support
> > the same states. A few, do not support the "stopped" state, they move
> > from 'active' directly to 'destroy'.  This is also true for  storage
> > resources. After a VM is stopped (turned off), the storage and all its
> > data from the VM instantiation is immediately destroyed. That is, unless
> > you purchase persistent storage and copy the information from the
> > volatile disk to the persistent one.  We also encounter a similar
> > practices with network IP addresses.
> >
> > Sam did develop a workaround for VM lifecycles, where next valid states
> > are included with current state information. However, it still does not
> > over ride the provider's practice or exclude a consumer's requirement
> > for the unsupported state.
> >
> > As an informative model, I think it can help communicate the basic
> > concepts of vm lifecycles.
> >
> > -gary
> >
> >
> >
> > Alexis Richardson wrote:
> >
> >> Sam,
> >>
> >> On the occi-wg call last week, we agreed to provide a reference model.
> >>  Whether this needs to be normative or otherwise is TBD.  But, we need
> >> to show folks a recommended model to implement, in order to increase
> >> understanding and bring in adopters.  Those adopters whose models
> >> differ from the example could either implement their own model with
> >> OCCI's protocol, or get involved in the community to adapt the
> >> recommended model.
> >>
> >> alexis
> >>
> >>
> >>
> >>
> >> On Sun, Feb 21, 2010 at 9:10 PM, Sam Johnston <samj at samj.net> wrote:
> >>
> >>
> >>> Copying list...
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: "Sam Johnston" <samj at samj.net>
> >>> Date: 21 Feb 2010 22:09
> >>> Subject: Re: [occi-wg] [Fwd: Simplified OCCI VM lifecycle diagram]
> >>> To: "Gary Mazz" <garymazzaferro at gmail.com>
> >>>
> >>> Gary,
> >>>
> >>> The problem with state diagrams is that if your implementation doesn't
> fit
> >>> the mould then you can't use OCCI.
> >>>
> >>> For example, you can't stop a resource with rackspacecloud, only
> destroy it.
> >>>
> >>> Something like this is probably useful as an informative rather than
> >>> normative reference.
> >>>
> >>> Sam
> >>>
> >>>
> >>>
> >>>> On 21 Feb 2010 21:35, "Gary Mazz" <garymazzaferro at gmail.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> As per the week...
> >>>>
> >>>>
> >>> _______________________________________________
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> 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
> > -------------------------------------------------------------
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100222/c1619156/attachment.html