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 :|