[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qapi: Reintroduce CommandDisabled error class
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH] qapi: Reintroduce CommandDisabled error class |
Date: |
Thu, 29 Aug 2019 14:10:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Michal Privoznik <address@hidden> writes:
> If there was a disabled command, then qemu-ga used to report
> CommandDisabled error class (among with human readable
> description). This changed in v1.2.0-rc0~28^2~16 in favor of
> GenericError class.
Really? I believe it was slightly earlier in the same series:
93b91c59db qemu-ga: switch to the new error format on the wire
de253f1491 qmp: switch to the new error format on the wire
The commit you mention (df1e608a01e) is merely follow-up simplification.
> While the change might work for other
> classes, this one should not have been dropped because it helps
> callers distinguish the root cause of the error.
>
> A bit of background: up until very recently libvirt used qemu-ga
> in all or nothing way. It didn't care why a qemu-ga command
> failed. But very recently a new API was introduced which
> implements 'best effort' approach (in some cases) and thus
> libvirt must differentiate between: {CommandNotFound,
> CommandDisabled} and some generic error. While the former classes
> mean the API can issue some other commands the latter raises a
> red flag causing the API to fail.
Why do you need to distinguish CommandNotFound from CommandDisabled?
> This reverts df1e608a01 partially.
>
> Signed-off-by: Michal Privoznik <address@hidden>