From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2QYf-0004bk-3C for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:10:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2QYc-0002TJ-OS for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:09:48 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:36042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2QYc-0002T8-Fa for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:09:46 -0500 Received: by pbcuo1 with SMTP id uo1so476905pbc.4 for ; Tue, 28 Feb 2012 09:09:44 -0800 (PST) Sender: fluxion Date: Tue, 28 Feb 2012 11:09:38 -0600 From: Michael Roth Message-ID: <20120228170938.GC2725@illuin> References: <2c332c139b3d6b38e2ef93e2efc951f8565c4a52.1329649806.git.mprivozn@redhat.com> <20120223122034.728c259c@doriath.home> <4F4BD034.5030400@redhat.com> <20120228020728.GB2725@illuin> <20120228112222.31482e44@doriath.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120228112222.31482e44@doriath.home> Subject: Re: [Qemu-devel] [PATCH v4] qemu-ga: Add guest-network-info command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Michal Privoznik , qemu-devel@nongnu.org On Tue, Feb 28, 2012 at 11:22:22AM -0300, Luiz Capitulino wrote: > On Mon, 27 Feb 2012 20:07:28 -0600 > Michael Roth 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. >