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@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@SOI (helps that he sits across from me) and it should be possible to have more specific use cases contributed from us in SLA@SOI
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Alexis Richardson Sent: 17 April 2009 17:26 To: Sam Johnston Cc: occi-wg@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@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@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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@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.