Comment 3 for bug 1806770

Thank you for your bug report.

I'm trying to reproduce the error, but without success so far. This is what I'm doing:

Prepared an image with hardcoded root password to be used later via serial console: bionic-server-cloudimg-amd64.img

 openstack image create u1804 --container-format bare --disk-format qcow2 --public --file ~/bionic-server-cloudimg-amd64.img

Created two servers: vm0 is a ubuntu 18.04 so I have a DHCP client that can send a client ID. vm1 is just there so I can delete it to trigger reload_allocations() in the dhcp-agent. I assume port deletion on the same network should trigger reload_allocations(), but I did not verify it yet.

 openstack server create vm0 --flavor ds512M --image u1804 --nic net-id=private --wait
 openstack server create vm1 --flavor cirros256 --image cirros-0.3.5-x86_64-disk --nic net-id=private --wait

Access vm0 over its libvirt serial console:

 sudo virsh console $( openstack server show vm0 -f value -c OS-EXT-SRV-ATTR:instance_name )

Inside vm0 configure client ID for the DHCP client:

 vim /etc/dhcp/dhclient.conf
 add line: send dhcp-client-identifier "CLIENT-FOO";

On the dhcp-agent's host start snooping the dnsmasq interface for DHCP traffic:

 sudo ip netns exec qdhcp-"$( openstack network show private -f value -c id )" ip a # pick the interface name
 sudo ip netns exec qdhcp-"$( openstack network show private -f value -c id )" tcpdump -vvv -s0 -i tap4204ce00-e0 | less

Again inside vm0 release and re-acquire the lease to prove I see the relevant DHCP traffic in tcpdump:

 dhclient -v -r
 dhclient -v ens2 -cf /etc/dhcp/dhclient.conf

I do see the DHCP packets. I see the client ID in the DHCP RELEASE, DISCOVER and REQUEST.

But then when I delete vm1 (openstack server delete vm1) I don't see a single DHCPRELEASE. I was expecting to see the storm you described. What am I missing?