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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list