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(a)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<h...
>> then Michal had sent a patch too (refer:
>>
http://www.mail-archive.com/**libvir-list@redhat.com/**msg57141.html<h...).
>> 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