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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Gary Mazz
> Sent: Sunday, February 21, 2010 11:04 PM
> To: Alexis Richardson
> Cc: occi-wg@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@samj.net> wrote:
>>
>>
>>> Copying list...
>>>
>>> ---------- Forwarded message ----------
>>> From: "Sam Johnston" <samj@samj.net>
>>> Date: 21 Feb 2010 22:09
>>> Subject: Re: [occi-wg] [Fwd: Simplified OCCI VM lifecycle diagram]
>>> To: "Gary Mazz" <garymazzaferro@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@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> As per the week...
>>>>
>>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg@ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>
>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg@ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>
>>>
>>>
>>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg@ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>>
>>
>>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg@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@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg