[occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model

Fri Apr 17 11:41:07 CDT 2009

It occurs to me that this *gap* that you correctly pick out, could be
plugged quickly by describing the use cases for the core 15 or so
verbs Chris and Richard have been pitching.  Subsequent discussion has
often been about those use cases - explicitly or implicitly.

On Fri, Apr 17, 2009 at 5:30 PM, Edmonds, AndrewX
<andrewx.edmonds at intel.com> wrote:
> Agreed *10 and don't forget Gall's Law :-)
>
> There is also currently a big gap between requirement extraction from use cases passing on into the API design so process-wise there's a piece of continuity massaging to be done.
>
> On use cases, I've been talking to the lead of the use case specifications within SLA at SOI (helps that he sits across from me) and it should be possible to have more specific use cases contributed from us in SLA at SOI
>
> Andy
>
> -----Original Message-----
> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Alexis Richardson
> Sent: 17 April 2009 17:26
> To: Sam Johnston
> Cc: occi-wg at ogf.org
> Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model
>
> +1,000 to "mimimalist"
>
> At least until we know more about what we are doing.
>
>
> On Fri, Apr 17, 2009 at 5:22 PM, Sam Johnston <samj at samj.net> wrote:
>> Ok so now that thing have quietened down a bit and I've had some time to
>> reflect I think there's a better way.
>>
>> Things like state diagrams are surprisingly emotive. People have a mental of
>> how things [should] work and they like the products they use to fit that
>> picture. Some people don't care about intermediary states like "starting"
>> but others (like me) don't have the patience to sit around waiting for
>> results without feedback. My point is that for every one of us there's
>> probably two potential solutions to this problem. We need to standardise so
>> that people can interoperate. If I see a machine that is "stopped" there
>> should be a "start" button and vice versa, but beyond that we don't need to
>> say much.
>>
>> Another facet is that we don't know every use case for this API so people
>> need to be able to extend it, and if they are going to do so then they
>> should do it in a coordinated fashion. Someone may want to add a
>> "transmogrifying" state to indicate that an OVF machine is being converted
>> to the native format (which can take a while). Some other sick and twisted
>> individual might decide to implement live migrations over SMTP for those
>> special "enterprise environments" so they want to have a "sending" and
>> "receiving" state - in fact these could already be useful for transferring
>> workloads between implementations.
>>
>> The single best way for us to solve this is to specify what we need to
>> specify for the level of interoperability we plan to achieve and then
>> maintain a registry for everything else. That allows us to be minimalist in
>> the API spec itself and pre-populate the registry with informative states
>> like "[re]starting", "restoring", etc.
>>
>> Another potentially interesting enhancement is feedback in terms of
>> progress, ETAs, etc. as these tend to be critical for user experience...
>> particularly clever providers might track the average startup time for a
>> certain machine for example and expose this so the client can run a
>> (relatively accurate) progress bar.
>>
>> Sam
>>
>> On Fri, Apr 17, 2009 at 4:56 PM, Lars Larsson <larsson at cs.umu.se> wrote:
>>>
>>> >> I suggest that we use the states shown at page 25 in "CIM System
>>> >> Virtualization White Paper" by the DMTF (DSP2013), available
>>> >> here:
>>> >>
>>> >>
>>> >>  http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf
>>> >
>>> > That is an interesting model - it seems a lot of people have
>>> > been thinking hard about that :-)   I like it...
>>> >
>>> > To play the devils advocate though:
>>> >
>>> >  - Is that state model suitable for our use cases?  It
>>> >    seems to allow for quite a large number of transissions,
>>> >    but is missing the 'Initial -> Suspended' transition
>>> >    which has been discussed on this list earlier.
>>> >
>>> >  - The design seems to have been motivated by physical
>>> >    states rather than logical states (the power state notes
>>> >    are an artifact of that I guess?).  Are the states
>>> >    applicable to our use cases?
>>>
>>> My interpretation of the CIM set of states is that the "Initial"
>>> state is a state that the VM has before it has even been defined
>>> or been allocated resources at the (virtual) hardware level.
>>> Such a system has never been in a previous state, and so cannot
>>> reasonably go to any other state than that of a shut down system
>>> with no prior state from which it has been suspended.
>>>
>>> I agree that this type of state model may be insufficient, e.g.
>>> because it is possible that we want to be able to submit a VM
>>> that has indeed been running somewhere else into the cloud (so
>>> while it is new to the cloud, it *does* have a prior state and
>>> is currently suspended).
>>>
>>> Such special scenarios may of course be supported by allowing a
>>> state definition to be made upon submission of the VM to the
>>> cloud infrastructure, but doing so certainly circumvents the
>>> semantics of the CIM model.
>>>
>>> >  - Do we need a distinction between 'VS State' and 'Enabled
>>> >    State'?  The document says: " the EnabledState property
>>> >    represents the virtual systemâ??s state" - so, what is the
>>> >    difference to VS state, which is, I take, also the
>>> >    virtual system state?  The document does not offer a
>>> >    better definition/distinction AFICS.
>>>
>>> This is again just my interpretation, but I think that the
>>> EnabledState is used to denote that the VM actively requires
>>> resources from the hypervisor of some sort, whereas the VS
>>> (Virtual System) state is the state from the point of view of
>>> the user and guest operating system (and PowerState is the
>>> mapping to physical hardware, which seems to have been a great
>>> inspiration to the creators of the model, I agree).
>>>
>>> So to answer your question if we need them a distinction or not
>>> -- no, we do not. If my interpretation is correct, the different
>>> kinds of state are just different perspectives of the same
>>> thing, so there is no actual distinction to begin with.
>>>
>>> -- Lars
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> occi-wg mailing list
> occi-wg at 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.
>