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

[Alexis Richardson]

+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
>
>