Re: [Qemu-devel] Adding errno to QMP errors

[Luiz Capitulino]

On Mon, 18 Jun 2012 13:31:52 -0500
Anthony Liguori <address@hidden> wrote:

> >> Are any users of QMP actually asking for this kind of advanced
> >> error reporting ?  From libvirt's POV we're perfectly content
> >> with just an error class&  string.
> >
> > Real users, please, not theoretical ones.
> 
> Irrespective of anything else, I think it's safe to say the experiment of 
> "rich 
> errors" has been a failure.  

Yes, I fully agree.

> We still have way too many places using error_report.
> 
> As I mentioned in another thread, I think we should:
> 
> 1) Introduce a GENERIC_ERROR QError type.  It could have a 'domain' and a 
> 'msg' 
> field.
> 
> 2) Focus on converting users of error_report over to use propagated Error 
> objects.

I agree with this too and the conversion itself can mostly be automated
I think. However, I think this is a related, but different problem (more below).

> We shouldn't/can't change existing QError users.  We also shouldn't consider 
> changing the wire protocol.  But for new error users, we should/can relax the 
> reported errors.

Can we agree on what 'relax' actually means?

In the very beginning of QMP, Markus had an idea of making errors absurdly
simple iirc it was just three general classes and a message (am I right,
Markus)?

Daniel seems to suggest something along these lines too. However, in my
understanding we're going to have two kinds of errors:

 1. OS errors: system calls or library functions errors. They will look
    like this:

     { "error": "OpenFileFailed", "filename": "/tmp/foo",
       "os-error": "nospace" }

    This means that, for every system call we're going to have a FOOFailed.
    Not sure this is reasonable.

 2. Anything else that doesn't fall in item 2, iow command specific errors,
    like InvalidBlockFormat.

Is this we really want to have? This is an honest question.

Btw, I think we first have to decide what we really want and afterwards we
discuss compatibility. I'm not saying we'll break it, but we might be able
to move forward and still maintain compatibility depending on what we want.

> We need a clear support policy on whether the contents of 'msg' are stable or 
> not too.

It's already declared on the qmp spec as not stable:

- The "desc" member is a human-readable error message. Clients should
  not attempt to parse this message.

Also, the qmp-commands.txt is very strong on error compatibility:

    3. Errors, in special, are not documented. Applications should NOT check
       for specific errors classes or data (it's strongly recommended to only
       check for the "error" key)

This is a bit unrealistic today though, as this was written when we were
still unsure about QMP's future and errors are getting documented in the
schema anyway.