[occi-wg] Simplified OCCI VM lifecycle diagram

[Sam Johnston]

On Thu, Sep 3, 2009 at 7:20 PM, <shlomo.swidler at 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 at samj.net> wrote:
>
>> On Thu, Sep 3, 2009 at 7:05 PM, gary mazzaferro <garymazzaferro at 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 at 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 at 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 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090903/5531b40d/attachment.html