We "kill -HUP 21237" the dnsmasq and immediately issue a dhcp_release, you can see in syslog.txt that the HUP reaches dnsmasq while it is reloading. As a result screen-n-dhcp does not show a 'del' at all (nor is there a DHCPRELEASE in syslog)
In fact during the reload dnsmasq sends a 'old' to the dhcp script. So we probably have to wait for the reload to finish (sleep?) before we call dhcp_release.
Here's a lead on the gate-grenade-dsvm - http:// paste.openstack .org/show/ 484637/
We "kill -HUP 21237" the dnsmasq and immediately issue a dhcp_release, you can see in syslog.txt that the HUP reaches dnsmasq while it is reloading. As a result screen-n-dhcp does not show a 'del' at all (nor is there a DHCPRELEASE in syslog)
In fact during the reload dnsmasq sends a 'old' to the dhcp script. So we probably have to wait for the reload to finish (sleep?) before we call dhcp_release.
Note that we can't switch order of HUP and release because it causes other problems : git.openstack. org/cgit/ openstack/ nova/tree/ nova/network/ manager. py#n1048
http://