Reviewed: https://review.openstack.org/560703 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fab032b426e1fa89dc473c61cbf15377fe4aaff3 Submitter: Zuul Branch: master
commit fab032b426e1fa89dc473c61cbf15377fe4aaff3 Author: Brian Haley <[email protected]> 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: Ic1864f7efbc94db1369ac7f3e2879fda86f95a11 Closes-bug: #1764481 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1764481 Title: Sometimes dhcp_releasepackets don't reach dnsmasq Status in neutron: Fix Released Bug description: We have seen issues downstream where calling dhcp_release didn't cause the lease to be removed from the leases files used by dnsmasq. There are a couple of scenarios where this could happen: 1. The packet is simply lost, as it is UDP, even though it's being looped-back 2. dnsmasq is reloading, so there is noone to receive it when it arrives For that reason we should make this more robust. A couple of possible solutions are: 1. Send the release more than once in succession. It's probably OK to just send some small number of packets for each lease we want to release, it would easily increase the odds that one makes it through. 2. Check the leases file to make sure dnsmasq processed the release, and re-send for those addresses that were missed. This method is slightly more complicated, but it should also increase the odds, and should do it with fewer packets being generated. Each option has some overhead, but since the option is not releasing the lease, it's worth it. I have proposed option #2 already at https://review.openstack.org/#/c/560703/ but wanted to make sure to get feedback on other proposals that might also solve the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1764481/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
