Re: [Qemu-devel] [RFC] Fixing the error failure

[Luiz Capitulino <lcapitulino@redhat.com>]

On Mon, 02 Jul 2012 07:47:56 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> > So far, there haven't been any calls for a change of the wire protocol.
> 
> Changing all existing errors and repurposing 'desc' is effectively changing the 
> wire protocol.

We're not going to change existing errors and I disagree that making 'desc'
a "free" string is an incompatible change, as we note in the spec that it
shouldn't be parsed.

> > There has been an agreement of sorts that the current "rich errors" have
> > been "a failure" (your words).  Doesn't mean we all agree on the nature
> > of the failure.
> >
> > Several people pointed out that:
> >
> > * our "rich" errors are so cumbersome to emit that adoption has been
> >    slow,
> >
> > * our "rich" errors' human-readable descriptions lead to piss-poor
> >    human-readable error messages[*] (pardon my french), and
> >
> > * the "richness" has no known uses after 2+ years.
> 
> Do you know of *any* QMP user beyond libvirt?  

Apart from casual people scripting around QMP, no I don't. But that doesn't
imply they don't exist.

> Let's face it, QMP is a protocol 
> for libvirt.  What it looks like shouldn't be dictated by anything other than 
> what libvirt wants/needs.
> 
> If libvirt isn't going to do more than look at an error type, then there's no 
> point in providing more than that.

They have asked us to turn 'desc' into a free string and I believe this is
a good change.

> The real problem we need to solve is not the quality of error messages. 
> Honestly, we have all of the tools today to improve error messages.
> 
> The problem we need to solve is error propagation because without it, we cannot 
> have asynchronous commands.  We keep ending up with extremely complex/cumbersome 
> management interfaces that we need to support forever because we still have 
> out-of-band errors that cannot be associated with a specific QMP command.
> 
> So I don't want to see us focus a bunch of effort on rewriting existing error 
> users.  Is that a hard and fast rule?  Of course not.  If it makes sense to 
> tweak an error here and there, that's fine.
> 
> But the problem to solve is killing off error_report.

I agree this is an important problem too.