On Mon, 02 Jul 2012 07:47:56 -0500 Anthony Liguori <anth...@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.