On 13 May 2009, at 15:50, Chris Webb wrote:

Sam Johnston <samj@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