On 25/07/13 19:13, Daniel P. Berrange wrote:
On Thu, Jul 25, 2013 at 07:01:05PM +0800, Osier Yang wrote:
> On 25/07/13 18:53, Daniel P. Berrange wrote:
>> On Thu, Jul 25, 2013 at 06:43:00PM +0800, Osier Yang wrote:
>>> 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.
>> We've already discussed this in the context of the virDomain API for
>> getting IP addresses & decided that virTypedParameter was not appropriate
>> there & we'd use a struct. The same arguments apply here IMHO.
>>
> the api to get the ip addresses is more complicate than this, and we
> finally chose the struct is because of the multiple level information
> is hard to constuct with typed parameter, but for this api, it's different,
> as it just needs to return the file paths.
No, file paths will absolutely never be exposed outside of the bridge
driver. The API I suggest above are about exposing the IP address + MAC
address of current leases. ie the actual data the user needs, *not* the
file path containing the data which is a private impl detail.