Simplified OCCI VM lifecycle diagram
Hi, I put together a simplified version of the OCCI life cycle (state) diagram. I'll be using this as an overview and for discussion purposes. I'll provide a description in a couple of days. -gary
Gary, While I still don't think we need nor want to lock down a state diagram, if we were to recommend one this looks fairly sensible. Reality is that if we mandate anything it won't mesh with all implementations so we'll exclude people unnecessarily. Sam On Thu, Sep 3, 2009 at 4:27 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
Hi,
I put together a simplified version of the OCCI life cycle (state) diagram. I'll be using this as an overview and for discussion purposes. I'll provide a description in a couple of days.
-gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Sam, True, we are not locking down any vendor to any specific implementation. At this date, OCCI does not have a attribute or operations defined for life cycle management. OCCI does have to operate with provider implementations that do support life cycles. We need to at least recognize those most basic life cycles in terms of permissible API operations. For example, a provider may not permit the deletion of an "active" VM. We will have recognize the most rudimentary life cycle states to offer consistent error or exception codes for operations in cases where providers do support life cycles. If you feel that an "occi life cycle" recommendation is needed at this point, we should discuss it. For now, I would prefer to report provider life cycle states mapped to occi enumerated state "values". -gary On Thu, Sep 3, 2009 at 10:19 AM, Sam Johnston <samj@samj.net> wrote:
Gary,
While I still don't think we need nor want to lock down a state diagram, if we were to recommend one this looks fairly sensible. Reality is that if we mandate anything it won't mesh with all implementations so we'll exclude people unnecessarily.
Sam
On Thu, Sep 3, 2009 at 4:27 PM, Gary Mazz <garymazzaferro@gmail.com>wrote:
Hi,
I put together a simplified version of the OCCI life cycle (state) diagram. I'll be using this as an overview and for discussion purposes. I'll provide a description in a couple of days.
-gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Thu, Sep 3, 2009 at 7:05 PM, gary mazzaferro <garymazzaferro@gmail.com>wrote:
If you feel that an "occi life cycle" recommendation is needed at this point, we should discuss it. For now, I would prefer to report provider life cycle states mapped to occi enumerated state "values".
Right, that's more or less what I had in mind - I'll be happy if we're not locking anyone down to any particular approach, because you can be sure the second we do someone will want something else (the ability to "destroy" an active resource being an obvious one). The fact that "destroy" maps directly to the "DELETE" verb rather than a state transition is another example of a reason to avoid overspecifying it. I do think we could afford to give guidance in this department though - both in the form of a normative state table and an informative state diagram (that is, a "may" or "should" requirement level). Cheers, Sam On Thu, Sep 3, 2009 at 10:19 AM, Sam Johnston <samj@samj.net> wrote:
Gary,
While I still don't think we need nor want to lock down a state diagram, if we were to recommend one this looks fairly sensible. Reality is that if we mandate anything it won't mesh with all implementations so we'll exclude people unnecessarily.
Sam
On Thu, Sep 3, 2009 at 4:27 PM, Gary Mazz <garymazzaferro@gmail.com>wrote:
Hi,
I put together a simplified version of the OCCI life cycle (state) diagram. I'll be using this as an overview and for discussion purposes. I'll provide a description in a couple of days.
-gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Will we also provide an API to discover the lifecycle capabilities of the provider? Or the lifecycle that is applicable for a specific abstract category of resource, or a specific actual resource? These capabilities are important in order to support the use case of a "cloud broker". On Thu, Sep 3, 2009 at 8:13 PM, Sam Johnston <samj@samj.net> wrote:
On Thu, Sep 3, 2009 at 7:05 PM, gary mazzaferro <garymazzaferro@gmail.com>wrote:
If you feel that an "occi life cycle" recommendation is needed at this point, we should discuss it. For now, I would prefer to report provider life cycle states mapped to occi enumerated state "values".
Right, that's more or less what I had in mind - I'll be happy if we're not locking anyone down to any particular approach, because you can be sure the second we do someone will want something else (the ability to "destroy" an active resource being an obvious one). The fact that "destroy" maps directly to the "DELETE" verb rather than a state transition is another example of a reason to avoid overspecifying it.
I do think we could afford to give guidance in this department though - both in the form of a normative state table and an informative state diagram (that is, a "may" or "should" requirement level).
Cheers,
Sam
On Thu, Sep 3, 2009 at 10:19 AM, Sam Johnston <samj@samj.net> wrote:
Gary,
While I still don't think we need nor want to lock down a state diagram, if we were to recommend one this looks fairly sensible. Reality is that if we mandate anything it won't mesh with all implementations so we'll exclude people unnecessarily.
Sam
On Thu, Sep 3, 2009 at 4:27 PM, Gary Mazz <garymazzaferro@gmail.com>wrote:
Hi,
I put together a simplified version of the OCCI life cycle (state) diagram. I'll be using this as an overview and for discussion purposes. I'll provide a description in a couple of days.
-gary
_______________________________________________ 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
On Thu, Sep 3, 2009 at 7:20 PM, <shlomo.swidler@gmail.com> wrote:
Will we also provide an API to discover the lifecycle capabilities of the provider? Or the lifecycle that is applicable for a specific abstract category of resource, or a specific actual resource?
These capabilities are important in order to support the use case of a "cloud broker".
I have just added a discovery capability last week which covers the resource types or "kinds", categories, [open]search, etc. - we may be able to enumerate the state machine if it makes sense to do so (maybe it does - I'm not sure - maybe it makes more sense as an extension). I'm not sure how this is critical for the "cloud broker" use case, but regardless we will be advertising possible state transitions via link relations. Sam
On Thu, Sep 3, 2009 at 8:13 PM, Sam Johnston <samj@samj.net> wrote:
On Thu, Sep 3, 2009 at 7:05 PM, gary mazzaferro <garymazzaferro@gmail.com
wrote:
If you feel that an "occi life cycle" recommendation is needed at this point, we should discuss it. For now, I would prefer to report provider life cycle states mapped to occi enumerated state "values".
Right, that's more or less what I had in mind - I'll be happy if we're not locking anyone down to any particular approach, because you can be sure the second we do someone will want something else (the ability to "destroy" an active resource being an obvious one). The fact that "destroy" maps directly to the "DELETE" verb rather than a state transition is another example of a reason to avoid overspecifying it.
I do think we could afford to give guidance in this department though - both in the form of a normative state table and an informative state diagram (that is, a "may" or "should" requirement level).
Cheers,
Sam
On Thu, Sep 3, 2009 at 10:19 AM, Sam Johnston <samj@samj.net> wrote:
Gary,
While I still don't think we need nor want to lock down a state diagram, if we were to recommend one this looks fairly sensible. Reality is that if we mandate anything it won't mesh with all implementations so we'll exclude people unnecessarily.
Sam
On Thu, Sep 3, 2009 at 4:27 PM, Gary Mazz <garymazzaferro@gmail.com>wrote:
Hi,
I put together a simplified version of the OCCI life cycle (state) diagram. I'll be using this as an overview and for discussion purposes. I'll provide a description in a couple of days.
-gary
_______________________________________________ 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
It's important for a cloud broker because I want to stipulate, e.g., "I need n VMs that can be suspended and do not cost money when in that state". Enumerating the state machine is one way to support that. It's expensive, though, isn't it? And advertising the state transitions only works for an actual resource, and it only allows you to see "one step" ahead, not the entire state transition diagram - unless I'm willing to push the buttons and change my resource's state. Anyway I think we're into extension territory here. .. Shlomo On Thu, Sep 3, 2009 at 8:36 PM, Sam Johnston <samj@samj.net> wrote:
On Thu, Sep 3, 2009 at 7:20 PM, <shlomo.swidler@gmail.com> wrote:
Will we also provide an API to discover the lifecycle capabilities of the provider? Or the lifecycle that is applicable for a specific abstract category of resource, or a specific actual resource?
These capabilities are important in order to support the use case of a "cloud broker".
I have just added a discovery capability last week which covers the resource types or "kinds", categories, [open]search, etc. - we may be able to enumerate the state machine if it makes sense to do so (maybe it does - I'm not sure - maybe it makes more sense as an extension).
I'm not sure how this is critical for the "cloud broker" use case, but regardless we will be advertising possible state transitions via link relations.
Sam
On Thu, Sep 3, 2009 at 8:13 PM, Sam Johnston <samj@samj.net> wrote:
On Thu, Sep 3, 2009 at 7:05 PM, gary mazzaferro < garymazzaferro@gmail.com> wrote:
If you feel that an "occi life cycle" recommendation is needed at this point, we should discuss it. For now, I would prefer to report provider life cycle states mapped to occi enumerated state "values".
Right, that's more or less what I had in mind - I'll be happy if we're not locking anyone down to any particular approach, because you can be sure the second we do someone will want something else (the ability to "destroy" an active resource being an obvious one). The fact that "destroy" maps directly to the "DELETE" verb rather than a state transition is another example of a reason to avoid overspecifying it.
I do think we could afford to give guidance in this department though - both in the form of a normative state table and an informative state diagram (that is, a "may" or "should" requirement level).
Cheers,
Sam
On Thu, Sep 3, 2009 at 10:19 AM, Sam Johnston <samj@samj.net> wrote:
Gary,
While I still don't think we need nor want to lock down a state diagram, if we were to recommend one this looks fairly sensible. Reality is that if we mandate anything it won't mesh with all implementations so we'll exclude people unnecessarily.
Sam
On Thu, Sep 3, 2009 at 4:27 PM, Gary Mazz <garymazzaferro@gmail.com>wrote:
Hi,
I put together a simplified version of the OCCI life cycle (state) diagram. I'll be using this as an overview and for discussion purposes. I'll provide a description in a couple of days.
-gary
_______________________________________________ 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
participants (5)
-
Gary Mazz -
gary mazzaferro
-
Michael Behrens -
Sam Johnston -
shlomo.swidler＠gmail.com