[occi-wg] OCCI MC - State Machine Diagram

[Sam Johnston]

On Wed, May 13, 2009 at 6:35 PM, Roger Menday
<roger.menday at uk.fujitsu.com>wrote:

>
> On 13 May 2009, at 15:50, Chris Webb wrote:
>
>  Sam Johnston <samj at samj.net> writes:
>>
>>  So the question is do you ask a "RUNNING" resource to "STOP" by pressing
>>> a
>>> button in order to get it to the "STOPPED" state or do you update its
>>> status
>>> from "RUNNING" to "STOPPED". To me the latter is unclean because who are
>>> you
>>> to say you're going to get to that state immediately, or indeed that
>>> you'll
>>> even get there at all
>>>
>>
>> Indeed. We have a classic example of this in our own public cloud. For us,
>> guests can go away by being 'destroyed' (hard kill) or because the
>> operating
>> system inside has executed an ACPI power-down, essentially asking to be
>> destroyed.
>>
>> We have an action 'shutdown' which sends an ACPI power-button event to the
>> guest OS. This may result in a successful shutdown (leading to an ACPI
>> power-down and guest destruction), it may be ignored, or it may trigger
>> something completely different. (I've used it for server-wide SIGHUP-type
>> behaviour before.)
>>
>
> Maybe I miss something, but, given the above, and supposing it does go
> wrong (doesn't end up where you expected), how do you discover, a while
> later, why that it so ?


Capturing errors of any asynchronous action when we're relying heavily on
HTTP response codes is both difficult and necessary. I'd envisaged a windows
style EventLog extension that would IMO be the best place for it (that is
where it usually ends up, right?)


>
>
>> Because of this, even ignoring the delay in state change, it's not clear
>> that our 'shutdown' event meaningfully maps to any particular state change
>> because from outside the vm abstraction: we don't know what effect on
>> state
>> the power-button event will actually have!
>>
>
True, so I think we agree to stick with the verbs. It's conceivable that we
have verbs like "SYNC" (for storage devices) that don't result in state
changes too.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090513/e257d439/attachment.html