Daniel P. Berrange wrote:
> For further backgrou, the key end goal here is that in a QMP client, upon
> receipt of the 'RESET' event, we need to reliably & immediately determine
> why it occurred. eg, triggered by watchdog, or by guest OS request. There
> are actually 3 possible sequences
>
> - WATCHDOG + action=reset, followed by RESET. Assuming no intervening
> event can occurr, the client can merely record 'WATCHDOG' and interpret
> it when it gets the immediately following 'RESET' event
WATCHDOG is useful in it's own right. For example, a manager may
decide itself what action to take - such as resetting on the first
three watchdog triggers and then stopping the vm without reset - so
there wouldn't be any other event from qemu about the watchdog.
Because WATCHDOG is useful in some circumstances, I think for
consistency it should always be emitted.
> - RESET, followed by WATCHDOG + action=reset. The client doesn't know
> the reason for the RESET and can't wait arbitrarily for WATCHDOG since
> there might never be one arriving.
Bad. Avoid :-)
Actually, if there is a problem maintaining event order, this would be
ok as long as RESET includes the reason - then the listener knows to
wait for the WATCHDOG event.
> - RESET + source=watchdog. Client directly sees the reason
I think this is good, but it should be preceded by the WATCHDOG event as all.
So:
WATCHDOG action=reset
RESET reason=watchdog
By the way, if a listener attaches to qemu in the middle of this
operation, is it possible for it to receive one event but not the
other due to timing?
It might make sense to add the concept of "group of events" if this
could be a problem.
> The second scenario is the one I'd like us to avoid at all costs, since it
> will require the client to introduce arbitrary delays in processing events
> to determine cause. The first is slightly inconvenient, but doable if we
> can assume no intervening events will occur, between WATCHDOG and the
> RESET events. The last is obviously simplest for the clients.
The last isn't simple for clients that want to know when the watchdog
triggers, independent of reason. They would have to look for
different kinds of events, depending on how the watchdog is configured.
And, perhaps more importantly, they wouldn't work if more
action-options were added to the watchdog device.
-- Jamie
