[occi-wg] OCCI MC - State Machine Diagram

[Roger Menday]

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.)

Hi Chris,

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 ?

Roger

>
> 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!
>
> Cheers,
>
> Chris.


Roger Menday (PhD)
<roger.menday at uk.fujitsu.com>

Senior Researcher, Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
Tel: +44 (0) 208 606 4534


______________________________________________________________________
                                        
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
 not guarantee that it has not been intercepted or amended nor that it is
 virus-free.