Quoting [Lars Larsson] (Apr 17 2009):
>
> On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:
>
> > We do not need "migrated", that is an internal operation that can not
> > be requested using a Cloud API
>
> I fully agree with Ignacio.
>
> I think there is a difference between the set of states that a
> VM can be in, and the set of states that may be set using the
> API. The first set may be larger and include informational
> states such as "being migrated" or "being copied", but that does
> not mean that the user can actively request that a VM should be
> migrated.
Yes, I agree with that: active versus informational states.
Again, other state models in OGF represent such information
as substates, e.g. 'Migrating' might be expressed as a
substate of 'Running'. I am not saying this is how this
group should do state modeling, just for information...
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?
- 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.
> Displaying extra information, such as "being migrated" or "being
> copied" is up to the infrastructure provider to optionally add
> to the description of the state that is reported via monitoring.
+1
Best, Andre.
--
Nothing is ever easy.
_______________________________________________