Following will be the methods:
(i) Querying qemu-guest-agent
(ii) Getting info from dnsmasq.leases file
(iii) Using the nwfilter to snoop the traffic
(i) Querying qemu-guest-agent
(ii) Getting info from dnsmasq.leases file
(iii) Using the nwfilter to snoop the traffic
Valid values:
domifaddr <domain-name> qemu-ga
domifaddr <domain-name> dnsmasq
domifaddr <domain-name> snoop
Suggestions are welcome for the 'name' of values of the option 'method'.
The main idea behind using virTypedParameter: It gives us extensibility - as long as we tell the user how many interfaces and how many parameters per interface, then we can add more parameters per interface.
If we use structs, then extensibility is lost.
If we use XML, then first JSON output is parsed into XML, then XML is parsed. More effort is involved.
As I think the previous patches by Michal were not pushed upstream due to lack of extensibility.
On Tue, Jul 2, 2013 at 4:03 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
On Fri, Jun 28, 2013 at 03:56:10PM +0530, Nehal J. Wani wrote:What are valid values for '<method>' here ?
> 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@xxxxxxxxxx/msg51857.html and
> then Michal had sent a patch too (refer:
> http://www.mail-archive.com/libvir-list@xxxxxxxxxx/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>
IMHO both of these approaches to encoding the data in virTypedParameter
>
> 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}
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 :|
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list