Re: [Qemu-devel] [PATCH v4] qemu-ga: Add guest-network-info command

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On Tue, Feb 28, 2012 at 11:22:22AM -0300, Luiz Capitulino wrote:
> On Mon, 27 Feb 2012 20:07:28 -0600
> Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> 
> > What about something like this instead:
> > 
> > { 'enum': 'GuestIpAddressType',
> >   'data': [ 'ipv4', 'ipv6' ] }
> > 
> > { 'type': 'GuestIpAddress',
> >   'data': {'ip-address': 'str',
> >            'ip-address-type': 'GuestIpAddressType',
> >            'prefix': 'int'} }
> > 
> > { 'type': 'GuestNetworkInterface',
> >   'data': {'interface': {'name': 'str',
> >                          '*hardware-address': 'str',
> >                          '*ip-addresses': ['GuestIpAddress'] } } }
> > 
> > { 'type': 'GuestNetworkInfo',
> >   'data': { 'interfaces': ['GuestNetworkInterfaces'] } }
> > 
> > { 'command': 'guest-network-info',
> >   'returns': 'GuestNetworkInfo' }
> > 
> > In the future we might have:
> > 
> > { 'type': 'GuestNetworkInfo',
> >   'data': { 'interfaces': ['GuestNetworkInterfaces'],
> >             'routes': ['GuestNetworkRoute'],
> >             'bridges': ['GuestNetworkBridge'],
> >             'firewall-rules': ['firewall-rule'], # yikes
> >             etc. } }
> 
> Both approaches are fine to me, but another possibility is to split this into
> multiple commands, like guest-interfaces-info, guest-routes-info etc. This would
> allow for simpler commands with less clutter.

Hmm, I know Michal already sent a new version with my suggestions, but
you're right, splitting out the commands simplified both the responses,
and makes it easier to discover whether or not that information is
available, since you can look for the command in guest-info before
attempting it, rather than attempting it and then looking at the result.

So maybe just something this?:

{ 'type': 'GuestNetworkInterface',
  'data': { 'name': 'str',
            '*hardware-address': 'str',
            '*ip-addresses': ['GuestIpAddress'] } } }

{ 'command': 'guest-network-interfaces',
  'returns': ['GuestNetworkInterface'] }

Michal, does this seem reasonable to you?

> 
> > > Once we settle down on this I can send another version for review.
> > > Personally, if guest agent would report description (see my other e-mail
> > > [1]) I don't see big advantage in introducing dozens of error codes here.
> > 
> > descriptions are mapped to QERRs though, so it'd only be useful if you
> > defined specific errors for these cases. I agree with Luiz, but at the
> > same time it's not exactly tractable to enumerate all possible errors for every
> > command into a unique QERR except for common things like FD_NOT_FOUND. So maybe
> > just a QERR_QGA_INTERFACE_ENUMERATION_FAILED, that took a stringified error
> > message? I don't really have a strong opinion either way.
> 
> Well, turns out I'm not sure what to do here either. On the one hand it's a
> huge work (and probably unnecessary) to add all possible errors. On the other
> hand, it's really hard to debug a problem when all information you have is
> a generic error.
> 
> As this a relatively simple query command, I'm fine with simple/generic errors.
>