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.

On Mon, Feb 22, 2010 at 3:02 AM, Gary Mazz 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@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.

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg