Re: [libvirt] RFC: Introduce API to return configuration/state paths of the network driver

On 25/07/13 17:35, Daniel P. Berrange wrote: >On Thu, Jul 25, 2013 at 02:02:36PM +0530, Nehal J. Wani wrote: >>Currently, there is no API which returns configuration/state paths of the >>network driver. >>Although it is a private implementation of the network driver, I don't see >>any harm in >>making the locations public because although the locations might change, >>there will always >>be a location for these files. There is a need for this API to implement >>method 2 of the >>"API to query ip addresses of a given domain", refer: >>http://www.mail-archive.com/libvir-list@redhat.com/msg79793.html . It is >>required to parse >>the leases file generated by dnsmasq. So, this API will be used by the qemu >>driver, but it >>can also be made public, so that, if a user wants to know get some >>information from a >>configuration file, he can get the location from libvirt and analyze it on >>his own. Right now, >>there is an alternate way to get the info: by using >>networkDnsmasqLeaseFileNameDefault, >>defined in /src/network/bridge_driver.c Since this function is static, it >>is part of the private >>implementation and not visible outside. To make it public, the following >>hack is possible: >NACK, > >As I explained on IRC, the hypervisor drivers have no business accessing >the dnsmasq lease files from the bridge driver. This is considered to be >a private implementation detail. > >At a conceptual level, what you're after here is a list of all the IP, >mac address mappings of the virtual network. This information is useful >even outside the context of the hypervisor driver method you're working >on. So we should create formal APIs for exposing this, something like: > > virNetworkGetDHCPLeases(virNetworkPtr network, > virNetworkDHCPLeasePtr *leases, > unsigned int nleases); i'm wondering if it should be more than just the lease file path, e.g. also the $net.conf, $net-radvd.conf, etc, though they are useless now, but may be useful in future, i.e. to have a more general api than this one. and in that case, it should return an array of typed parameter instead.