Re: [Qemu-devel] Re: [PATCH 00/10]: QError v4

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

>> 2. It falls short of the requirement that clients can reasonably
>>     classify errors they don't know.
>
> True.  (Though adding a classification mechanism can be done later
> once we have an idea of what errors are there at all).

Yes.

If we think there's a risk screwing up the classification, because we
don't yet understand the errors sufficiently, and we think a screwup
would be is awkward to fix later, then deferring to a later iteration
would make sense.

>> 3. It falls short of the requirement that clients can easily present a
>>     human-readable error description to their human users, regardless of
>>     whether they know the error or not.
>
> That's true.  I would definitely have the interpolated desc field go
> on the wire too, as part of the JSON form of QError.

That would be my preference, too.

>> If I understand Dan correctly, machine-readable error code +
>> human-readable description is just fine, as long as the error code is
>> reasonably specific and the description is precise and complete.  Have
>> we heard anything else from client developers?
>
> Then (except for the asynchronicity) the current qemu monitor protocol
> is also just fine, including the fact that we send migrate and get
> m\rmi\rmig\rmigr etc. back on the socket.
>
> "error while creating snapshot on '%s'" may be easy to parse, but
> looking at a dictionary field in { "filename" : "blah.img" } is
> easier, and at the same time solves issues with escaping weird
> characters in the file name.

As soon as the client needs to know more than a (reasonably specific)
error code, structured error data helps.

But I can't see that need in your particular example.  The client asks
the server to create a snapshot.  The operation fails.  The client
already knows what the name of the snapshot is, doesn't it?  No need to
get it from the error.

>> * The crucial question for the client isn't "what exactly went wrong".
>>    It is "how should I handle this error".  Answering that question
>>    should be easy (say, check the error code).  Figuring out what went
>>    wrong should still be possible for a human operator of the client.
>
> The same error can be handled in a different way depending on the
> situation.  A missing image is in general a fatal error, but maybe
> another client could create images on the fly.

The latter client surely knows this error.

My question is how to help clients handle errors they don't know.  In
your example, the help would boil down to "this error is generally
fatal".

>> Based on what I've learned about client requirements so far, I figure
>> that solution is "easily classified error code + human-readable
>> description".
>
> How would you classify the error code?  By subsystem or by (for
> example) severity or anything else?  Does QEMU have subsystems that
> are well-identified enough to be carved in stone in QError?  (All
> genuine questions.  I have no idea).

My first cut (really just a shot from the hip) was[*]:

    Something like client error (i.e. your command was stupid, and
    trying again will be just as stupid), permanent server error (it
    wasn't stupid, but I can't do it for you), transient server error (I
    couldn't do it for you, but trying again later could help).


[*] Message-ID: <address@hidden>