[libvirt] RFC: 'old' event for leaseshelper.c when lease renews

[Nehal J Wani]

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.

(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.

(iii) We do nothing.

IMO, we should go for (i), since <network-name>.leases becomes
obsolete, once we have our own leases helper. Also, enabling
--leasefile-ro enables a lot of other options, like vendor-class,
user-class, circuit-id and much more, which may be asked for in future
and get added to the virNetworkDHCPLeases struct. But we will have to
remove the option --dhcp-leasefile. Although it won't affect any
existing APIs, if people did rely on the dnsmasq's generated leases
file before, they will find it missing. There is one more point. The
man page of dnsmasq for the leasefile-ro option, states, "In addition
to the invocations given in --dhcp-script the lease-change script is
called once, at dnsmasq startup, with the single argument "init". When
called like this the script should write the saved state of the lease
database, in dnsmasq leasefile format, to stdout and exit with zero
exit code." This is something extra that we will have to add to
leaseshelper if we go with (i).

The easier option is to go with (ii), since Simon is already willing
to add that functionality.




-- 
Nehal J Wani