On Fri, Jun 28, 2013 at 03:56:10PM +0530, Nehal J. Wani wrote:
Hello, fellow developers!
I am a GSoC candidate this year working for
libvirt.org. My
project is "Introduce API to query IP addresses for given domain".
The discussion regarding this feature had started here:
http://www.mail-archive.com/libvir-list@redhat.com/msg51857.html and
then Michal had sent a patch too (refer:
http://www.mail-archive.com/libvir-list@redhat.com/msg57141.html). But
it was not pushed upstream due to lack of extensibility.
So far I've come up with an API and I want to get your opinion before
I start writing the rest so I don't follow the wrong direction.
Following are the valid commands:
domifaddr <domain-name>
domifaddr <domain-name> <interface-name>
domifaddr <domain-name> <interface-name> <method>
domifaddr <domain-name> <method>
What are valid values for '<method>' here ?
methods:
(i) Querying qemu-guest-agent
(ii) Getting info from dnsmasq.leases file
(iii) Using the nwfilter to snoop the traffic
If no method is mentioned, qemu-guest-agent will be used.
Previous attempts by Michal had used structs and xml. Structs bring in
restrictions and xml has to be parsed. Hence I am not planning to
continue with either of these.
As a start, I would like to know your comments about my API which
queries the qemu-guest-agent and returns the results in
virTypedParameter **params.
Format(JSON) in which the qemu guest agent returns info:
[{"name":"lo",
"ip-addresses":
[{"ip-address-type":"ipv4","ip-address":"127.0.0.1","prefix":8},
{"ip-address-type":"ipv6","ip-address":"::1","prefix":128}],
"hardware-address":"00:00:00:00:00:00"},
{"name":"eth0",
"ip-addresses":
[{"ip-address-type":"ipv4","ip-address":"192.168.122.42","prefix":24},
{"ip-address-type":"ipv6","ip-address":"fe80::5054:ff:fe09:d240","prefix":64}],
"hardware-address":"52:54:00:09:d2:40"}]
//Possible 1-D Structure (A little hassle to maintain)
params[0] = {"iface-count",int,2}
params[1] = {"iface-name",string,"lo"}
params[2] = {"iface-hwaddr",string,"00:00:00:00:00:00"}
params[3] = {"iface-addr-count",int,2}
params[4] = {"iface-addr-type",string,"ipv4"}
params[5] = {"iface-addr",string,"127.0.0.1"}
params[6] = {"iface-addr-prefix",int,8}
params[7] = {"iface-addr-type",string,"ipv6"}
params[8] = {"iface-addr",string,"::1"}
params[9] = {"iface-addr-prefix",int,128}
....
....
....
//2D Structure: (Not very hasslefree, but easier to maintain as one
interface per row)
params[0] =
{"iface-name",string,"lo"}{"iface-hwaddr",string,"00:00:00:00:00:00"}{"iface-addr-type",string,"ipv4"}{"iface-addr",string,"127.0.0.1"}{"iface-addr-prefix",int,8}{"iface-addr-type",string,"ipv6"}{"iface-addr",string,"::1"}{"iface-addr-prefix",int,128}
params[1] =
{"iface-name",string,"eth0"}{"iface-hwaddr",string,"52:54:00:09:d2:40"}{"iface-addr-type",string,"ipv4"}{"iface-addr",string,"192.168.122.42"}{"iface-addr-prefix",int,8}{"iface-addr-type",string,"ipv6"}{"iface-addr",string,"fe80::5054:ff:fe09:d240"}{"iface-addr-prefix",int,64}
IMHO both of these approaches to encoding the data in virTypedParameter
are seriously unpleasant for an app to deal with. Now this is a true for
virTypedParameter in general, but I think that the need to deal with a
list of objects here, each containing a list of typed parameters makes
it even worse than normal. I wouldn't really like this as an application
developer.
Looking at this possible approach of virTypedParameter, I'm think I am
preferring either the XML or fixed struct approach to this API as was
proposed in the past, with a bias towards a fixed struct for simplicity
of use by app developers.
Regards,
Danuiel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|