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
wrote: Copying list...
---------- Forwarded message ---------- From: "Sam Johnston"
Date: 21 Feb 2010 22:09 Subject: Re: [occi-wg] [Fwd: Simplified OCCI VM lifecycle diagram] To: "Gary Mazz" 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"
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.