On 02/07/13 18:33, Daniel P. Berrange wrote:

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.

agreed.

after seeing the trouble caused by multiple addrs, i'm not sure about using virTypedParameter too. even if we have an array type value, it still looks like not easy to use for api user, one has to know how many elements of the array too.

 

Regards,
Danuiel