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

[Sam Johnston]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090417/329a2d84/attachment.html