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@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@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg