Sometimes calls to dhcp_release(6) do not result in removal
of a lease from the leases file, for example, when the release
packet is not received by dnsmasq. Trying more than once is
recommended in this case.
Instead of blindly trying some number of times, we monitor
the lease file contents, and retry the dhcp_release(6) call
when an entry still remains. This is possible since
dhcp_release(6) is being run from the DHCP server itself.
We try three times and wait 0.3 seconds between tries.
We also now check for any stale leases in the leases file
that are unknown to neutron, also trying to remove them.
Reviewed: https:/ /review. openstack. org/560703 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=fab032b426e 1fa89dc473c61cb f15377fe4aaff3
Committed: https:/
Submitter: Zuul
Branch: master
commit fab032b426e1fa8 9dc473c61cbf153 77fe4aaff3
Author: Brian Haley <email address hidden>
Date: Wed Apr 11 21:22:23 2018 -0400
Retry dhcp_release on failures
Sometimes calls to dhcp_release(6) do not result in removal
of a lease from the leases file, for example, when the release
packet is not received by dnsmasq. Trying more than once is
recommended in this case.
Instead of blindly trying some number of times, we monitor
the lease file contents, and retry the dhcp_release(6) call
when an entry still remains. This is possible since
dhcp_release(6) is being run from the DHCP server itself.
We try three times and wait 0.3 seconds between tries.
We also now check for any stale leases in the leases file
that are unknown to neutron, also trying to remove them.
Change-Id: Ic1864f7efbc94d b1369ac7f3e2879 fda86f95a11
Closes-bug: #1764481