[libvirt] RFC: Introduce API to query IP addresses for given domain

[Nehal J. Wani]

Eric, could you please share your opinion as to what should be more
appropriate to use for this functionality: Structs/XML/VirTypedParams ?


On Tue, Jul 2, 2013 at 7:25 PM, Osier Yang <jyang at redhat.com> wrote:

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


-- 
Nehal J. Wani
UG2, BTech CS+MS(CL)
IIIT-Hyderabad
http://commandlinewani.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130708/95ae6037/attachment-0001.htm>