On Sat, Jun 28, 2014 at 05:06:26AM +0530, Nehal J Wani wrote:
In the current version of dnsmasq, the leases helper script/program specified by --dhcp-script to dnsmasq is invoked on three events, 'add', 'old', 'del'. In short, add: -> a new lease has to be added to db del: -> a lease has to be deleted from db old:-> if lease has changed Now, the lease can be considered to be changed in 2 ways. [standard-change] The change could be to the associated hostname or MAC address [auxiliary-change] The change associated with expiry time or clientid
When only --dhcp-script is set, 'old' events are sent only for standard-lease changes. But when --dhcp-script is set along with --leasefile-ro, 'old' events are sent for any change in the lease.
So, right now, if a lease is renewed, the reflected change doesn't appear in our JSON formatted lease database <interface-name>.status. We have the following options with this:
(i) We can simply add the --leasefile-ro option. But in that case, the leases file database which is generated by dnsmasq by the name <network-name>.leases will cease to exist. It won't contain any lease information. All lease database handling will be done by our leaseshelper. Note: this option given a lot of information which is not stored in <network-name>.leases file.
What purpose does the <network-name>.leases file that dnsmasq creates serve ? If our own leases file is able to provide any funtionality that is missing due to the loss of <network-name>.leases, then this option seems like the best.
(ii) We ask the dnsmasq developer(s) to add an extra command line option to enable auxiliary changes in lease to be propagated to leaseshelper via 'old' events. I had a small conversation with Simon Kelley, and he said: "Yes. For that application (libvirt), you clearly don't want a third-party patch. At very least I'd be willing to add a boolean option to dnsmasq which enables "old" events when the lease expiry time changes, independent of leasefile-ro." If we do this, then can retain <network-name>.leases and have our helper too.
I'd prefer (i) since that lets libvirt work properly with existing dnsmasq versions which are deployed. Regards, Daniel -- |: 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 :|