[Qemu-devel] Plan for error handling in QMP

[Qemu-devel] Plan for error handling in QMP

[anthony]

Hi,

We had a violent^Wheated discussion on IRC about how to move forward
with Luiz's proposed error series.  I think we reached consensus.  This
note attempts to outline that.

Principles
----------
1. Errors should be free formed strings with a class code

2. There should be a small number of class codes (10-15) added
   strictly when there are specific users of a code.

3. The class code should be expressed as an enum data type in the normal
   QMP schema.  Other than this, errors should have no structure in the
   schema.[*]

4. We should drop all dictionary arguments in the current error
   mechanisms beyond 'class' and 'desc'.

5. The following errors are used by libvirt:
   - CommandNotFound: QMP parsing
   - DeviceNotActive/KVMMissingCap: ballooning
   - DeviceNotFound: drive_del
   - MigrationExpected: cont

6. We need to make sure that these errors are preserved while other
   errors should be consolidated.
   - We need to state very clear for 1.2 which errors are going away.

7. We need to make sure that anything we expose in 1.2 stays that way.
   If we're dropping 'InvalidParameterType' as a class code, it should be
   dropped in 1.2.  This could be achieved by making all existing codes
   except for those in (5) report 'UnknownError' or something.[*]

[*] I took a little bit of license with these.  Hopefully it's not
controversial.

Regards,

Anthony Liguori
   

Re: [Qemu-devel] Plan for error handling in QMP

[Luiz Capitulino]

On Thu, 26 Jul 2012 13:22:15 -0500
anthony@codemonkey.ws wrote:

> 
> Hi,
> 
> We had a violent^Wheated discussion on IRC about how to move forward
> with Luiz's proposed error series.  I think we reached consensus.  This
> note attempts to outline that.

This looks great to me, violent^W heated discussions can be so productive :)

> 
> Principles
> ----------
> 1. Errors should be free formed strings with a class code
> 
> 2. There should be a small number of class codes (10-15) added
>    strictly when there are specific users of a code.
> 
> 3. The class code should be expressed as an enum data type in the normal
>    QMP schema.  Other than this, errors should have no structure in the
>    schema.[*]
> 
> 4. We should drop all dictionary arguments in the current error
>    mechanisms beyond 'class' and 'desc'.
> 
> 5. The following errors are used by libvirt:
>    - CommandNotFound: QMP parsing
>    - DeviceNotActive/KVMMissingCap: ballooning
>    - DeviceNotFound: drive_del
>    - MigrationExpected: cont
> 
> 6. We need to make sure that these errors are preserved while other
>    errors should be consolidated.
>    - We need to state very clear for 1.2 which errors are going away.
> 
> 7. We need to make sure that anything we expose in 1.2 stays that way.
>    If we're dropping 'InvalidParameterType' as a class code, it should be
>    dropped in 1.2.  This could be achieved by making all existing codes
>    except for those in (5) report 'UnknownError' or something.[*]
> 
> [*] I took a little bit of license with these.  Hopefully it's not
> controversial.
> 
> Regards,
> 
> Anthony Liguori
>    
> 

Re: [Qemu-devel] Plan for error handling in QMP

[Luiz Capitulino]

On Thu, 26 Jul 2012 15:43:58 -0300
Luiz Capitulino <lcapitulino@redhat.com> wrote:

> On Thu, 26 Jul 2012 13:22:15 -0500
> anthony@codemonkey.ws wrote:
> 
> > 
> > Hi,
> > 
> > We had a violent^Wheated discussion on IRC about how to move forward
> > with Luiz's proposed error series.  I think we reached consensus.  This
> > note attempts to outline that.
> 
> This looks great to me, violent^W heated discussions can be so productive :)
> 
> > 
> > Principles
> > ----------
> > 1. Errors should be free formed strings with a class code
> > 
> > 2. There should be a small number of class codes (10-15) added
> >    strictly when there are specific users of a code.

Btw, do we have a listing of those 10-15 errors already?

Re: [Qemu-devel] Plan for error handling in QMP

[Anthony Liguori]

Luiz Capitulino <lcapitulino@redhat.com> writes:

> On Thu, 26 Jul 2012 15:43:58 -0300
> Luiz Capitulino <lcapitulino@redhat.com> wrote:
>
>> On Thu, 26 Jul 2012 13:22:15 -0500
>> anthony@codemonkey.ws wrote:
>> 
>> > 
>> > Hi,
>> > 
>> > We had a violent^Wheated discussion on IRC about how to move forward
>> > with Luiz's proposed error series.  I think we reached consensus.  This
>> > note attempts to outline that.
>> 
>> This looks great to me, violent^W heated discussions can be so productive :)
>> 
>> > 
>> > Principles
>> > ----------
>> > 1. Errors should be free formed strings with a class code
>> > 
>> > 2. There should be a small number of class codes (10-15) added
>> >    strictly when there are specific users of a code.
>
> Btw, do we have a listing of those 10-15 errors already?

See the clause: "added strictly when there are specific users".

Users means consumers.  So don't add an error type until someone cares
to differientiate error reasons.

Regards,

Anthony Liguori

Re: [Qemu-devel] Plan for error handling in QMP

[Luiz Capitulino]

On Thu, 26 Jul 2012 16:08:54 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> writes:
> 
> > On Thu, 26 Jul 2012 15:43:58 -0300
> > Luiz Capitulino <lcapitulino@redhat.com> wrote:
> >
> >> On Thu, 26 Jul 2012 13:22:15 -0500
> >> anthony@codemonkey.ws wrote:
> >> 
> >> > 
> >> > Hi,
> >> > 
> >> > We had a violent^Wheated discussion on IRC about how to move forward
> >> > with Luiz's proposed error series.  I think we reached consensus.  This
> >> > note attempts to outline that.
> >> 
> >> This looks great to me, violent^W heated discussions can be so productive :)
> >> 
> >> > 
> >> > Principles
> >> > ----------
> >> > 1. Errors should be free formed strings with a class code
> >> > 
> >> > 2. There should be a small number of class codes (10-15) added
> >> >    strictly when there are specific users of a code.
> >
> > Btw, do we have a listing of those 10-15 errors already?
> 
> See the clause: "added strictly when there are specific users".
> 
> Users means consumers.  So don't add an error type until someone cares
> to differientiate error reasons.

What I meant is that, for 1.2 we want to reduce from 71 error codes to 10-15,
right? If that's right what are the 10-15 errors that won't be dropped?

Or did I misunderstand?

Re: [Qemu-devel] Plan for error handling in QMP

[Anthony Liguori]

Luiz Capitulino <lcapitulino@redhat.com> writes:

> On Thu, 26 Jul 2012 16:08:54 -0500
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>> Luiz Capitulino <lcapitulino@redhat.com> writes:
>> 
>> > On Thu, 26 Jul 2012 15:43:58 -0300
>> > Luiz Capitulino <lcapitulino@redhat.com> wrote:
>> >
>> >> On Thu, 26 Jul 2012 13:22:15 -0500
>> >> anthony@codemonkey.ws wrote:
>> >> 
>> >> > 
>> >> > Hi,
>> >> > 
>> >> > We had a violent^Wheated discussion on IRC about how to move forward
>> >> > with Luiz's proposed error series.  I think we reached consensus.  This
>> >> > note attempts to outline that.
>> >> 
>> >> This looks great to me, violent^W heated discussions can be so productive :)
>> >> 
>> >> > 
>> >> > Principles
>> >> > ----------
>> >> > 1. Errors should be free formed strings with a class code
>> >> > 
>> >> > 2. There should be a small number of class codes (10-15) added
>> >> >    strictly when there are specific users of a code.
>> >
>> > Btw, do we have a listing of those 10-15 errors already?
>> 
>> See the clause: "added strictly when there are specific users".
>> 
>> Users means consumers.  So don't add an error type until someone cares
>> to differientiate error reasons.
>
> What I meant is that, for 1.2 we want to reduce from 71 error codes to 10-15,
> right? If that's right what are the 10-15 errors that won't be dropped?
>
> Or did I misunderstand?

I meant drop it down to 5-6.  The existing errors that libvirt cares
about plus an UnknownError.  #define all existing error codes to
UnknownError and then at our leisure, we can introduce more generic
classes and refactor errors incrementally.

Regards,

Anthony Liguori

Re: [Qemu-devel] Plan for error handling in QMP

[Luiz Capitulino]

On Thu, 26 Jul 2012 17:47:25 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> writes:
> 
> > On Thu, 26 Jul 2012 16:08:54 -0500
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> >
> >> Luiz Capitulino <lcapitulino@redhat.com> writes:
> >> 
> >> > On Thu, 26 Jul 2012 15:43:58 -0300
> >> > Luiz Capitulino <lcapitulino@redhat.com> wrote:
> >> >
> >> >> On Thu, 26 Jul 2012 13:22:15 -0500
> >> >> anthony@codemonkey.ws wrote:
> >> >> 
> >> >> > 
> >> >> > Hi,
> >> >> > 
> >> >> > We had a violent^Wheated discussion on IRC about how to move forward
> >> >> > with Luiz's proposed error series.  I think we reached consensus.  This
> >> >> > note attempts to outline that.
> >> >> 
> >> >> This looks great to me, violent^W heated discussions can be so productive :)
> >> >> 
> >> >> > 
> >> >> > Principles
> >> >> > ----------
> >> >> > 1. Errors should be free formed strings with a class code
> >> >> > 
> >> >> > 2. There should be a small number of class codes (10-15) added
> >> >> >    strictly when there are specific users of a code.
> >> >
> >> > Btw, do we have a listing of those 10-15 errors already?
> >> 
> >> See the clause: "added strictly when there are specific users".
> >> 
> >> Users means consumers.  So don't add an error type until someone cares
> >> to differientiate error reasons.
> >
> > What I meant is that, for 1.2 we want to reduce from 71 error codes to 10-15,
> > right? If that's right what are the 10-15 errors that won't be dropped?
> >
> > Or did I misunderstand?
> 
> I meant drop it down to 5-6.  The existing errors that libvirt cares
> about plus an UnknownError.  #define all existing error codes to
> UnknownError and then at our leisure, we can introduce more generic
> classes and refactor errors incrementally.

That's great, I've already started working on this and should post the
series soon.

Re: [Qemu-devel] Plan for error handling in QMP

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]

On 07/26/2012 12:22 PM, anthony@codemonkey.ws wrote:
> 
> Hi,
> 
> We had a violent^Wheated discussion on IRC about how to move forward
> with Luiz's proposed error series.  I think we reached consensus.  This
> note attempts to outline that.
> 
> Principles
> ----------
> 1. Errors should be free formed strings with a class code
> 
> 2. There should be a small number of class codes (10-15) added
>    strictly when there are specific users of a code.
> 
> 3. The class code should be expressed as an enum data type in the normal
>    QMP schema.  Other than this, errors should have no structure in the
>    schema.[*]
> 
> 4. We should drop all dictionary arguments in the current error
>    mechanisms beyond 'class' and 'desc'.
> 
> 5. The following errors are used by libvirt:
>    - CommandNotFound: QMP parsing
>    - DeviceNotActive/KVMMissingCap: ballooning
>    - DeviceNotFound: drive_del
>    - MigrationExpected: cont

DeviceInUse, NotSupported: block-stream

Search for qemuMonitorJSONHasError in src/qemu/qemu_monitor_json.c

> 
> 6. We need to make sure that these errors are preserved while other
>    errors should be consolidated.
>    - We need to state very clear for 1.2 which errors are going away.
> 
> 7. We need to make sure that anything we expose in 1.2 stays that way.
>    If we're dropping 'InvalidParameterType' as a class code, it should be
>    dropped in 1.2.  This could be achieved by making all existing codes
>    except for those in (5) report 'UnknownError' or something.[*]
> 
> [*] I took a little bit of license with these.  Hopefully it's not
> controversial.
> 
> Regards,
> 
> Anthony Liguori
>    
> 
> 

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [Qemu-devel] Plan for error handling in QMP

[Paolo Bonzini]

Il 26/07/2012 22:41, Eric Blake ha scritto:
>> > 5. The following errors are used by libvirt:
>> >    - CommandNotFound: QMP parsing
>> >    - DeviceNotActive/KVMMissingCap: ballooning
>> >    - DeviceNotFound: drive_del
>> >    - MigrationExpected: cont
> DeviceInUse, NotSupported: block-stream
> 
> Search for qemuMonitorJSONHasError in src/qemu/qemu_monitor_json.c
> 

These are only used for better error messages.  We can tolerate a brief
reduction in error message quality for now, in the meanwhile libvirt can
prepare to use the free-form messages for QEMU.  Having free-form error
messages will also help with internationalization.

Paolo

Re: [Qemu-devel] Plan for error handling in QMP

[Richard W.M. Jones]

On Thu, Jul 26, 2012 at 01:22:15PM -0500, anthony@codemonkey.ws wrote:
> We had a violent^Wheated discussion on IRC about how to move forward
> with Luiz's proposed error series.  I think we reached consensus.  This
> note attempts to outline that.
> 
> Principles
> ----------
> 1. Errors should be free formed strings with a class code
> 
> 2. There should be a small number of class codes (10-15) added
>    strictly when there are specific users of a code.

FWIW this is roughly the same scheme that libguestfs uses to report
errors: string + error code.  It's been quite successful, and IMHO is
much better than the large and ill-defined 'virterror' struct that
libvirt returns.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

Re: [Qemu-devel] Plan for error handling in QMP

[Markus Armbruster]

anthony@codemonkey.ws writes:

> Hi,
>
> We had a violent^Wheated discussion on IRC about how to move forward
> with Luiz's proposed error series.  I think we reached consensus.  This
> note attempts to outline that.
>
> Principles
> ----------
> 1. Errors should be free formed strings with a class code
>
> 2. There should be a small number of class codes (10-15) added
>    strictly when there are specific users of a code.
>
> 3. The class code should be expressed as an enum data type in the normal
>    QMP schema.  Other than this, errors should have no structure in the
>    schema.[*]
>
> 4. We should drop all dictionary arguments in the current error
>    mechanisms beyond 'class' and 'desc'.
>
> 5. The following errors are used by libvirt:
>    - CommandNotFound: QMP parsing
>    - DeviceNotActive/KVMMissingCap: ballooning
>    - DeviceNotFound: drive_del
>    - MigrationExpected: cont
>
> 6. We need to make sure that these errors are preserved while other
>    errors should be consolidated.
>    - We need to state very clear for 1.2 which errors are going away.
>
> 7. We need to make sure that anything we expose in 1.2 stays that way.
>    If we're dropping 'InvalidParameterType' as a class code, it should be
>    dropped in 1.2.  This could be achieved by making all existing codes
>    except for those in (5) report 'UnknownError' or something.[*]

I'd call it 'Error'.

> [*] I took a little bit of license with these.  Hopefully it's not
> controversial.

Forward progress!

ACK

Re: [Qemu-devel] Plan for error handling in QMP

[Paolo Bonzini]

Il 26/07/2012 20:22, anthony@codemonkey.ws ha scritto:
> 7. We need to make sure that anything we expose in 1.2 stays that way.
>    If we're dropping 'InvalidParameterType' as a class code, it should be
>    dropped in 1.2.  This could be achieved by making all existing codes
>    except for those in (5) report 'UnknownError' or something.[*]
> 
> [*] I took a little bit of license with these.  Hopefully it's not
> controversial.

Sounds great, just a note: I think that at the source level in 1.2 we
should not lose information on what was the "old" error type.  It will
guide the future conversion, also together with tables like
http://pastebin.com/kZtfFnFK.

So let's keep the names as "#define QERR_FOO UnknownError" for now.

Paolo