David, Maybe I misunderstand your question but I would expect this behavior. The "force_dhcp_release" flag says 'send a DHCP release to the DHCP server'. This doesn't mean that the IP is immediately available for use as it is still associated with the instance UUID in the nova database. The "fixed_ip_disassociate_timeout" flag disassociates the IP from the relevant instance in the nova.fixed_ips table after the specified time. Useful link: http://docs.openstack.org/folsom/openstack-compute/admin/content/list-of-compute-config-options.html Thanks, Kevin Rackspace From: David Hill <david.hill at ubisoft.com<mailto:david.hill at ubisoft.com>> Date: Friday, March 22, 2013 12:59 PM To: "openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>> Subject: [Openstack] DHCP release Hi guys, I’m experiencing some kind of weird behaviour with our openstack setup here. Let me explain: I create an instance that gets an IP: 172.0.0.3 I destroy the instance. I recreate an instance that will get another IP: 172.0.0.4. If I wait 600 seconds between each test, 172.0.0.3 will be attributed again instead of 172.0.0.4. Would it be possible that the IP de-allocation relies on the periodic task to do some clean up? I’m asking because actually this doesn’t work: force_dhcp_release=true dhcp_lease_time=604800 fixed_ip_disassociate_timeout=1209600 If I do this and stress test my lab, I will eventually run out of IPs! But this works: force_dhcp_release=true dhcp_lease_time=604800 fixed_ip_disassociate_timeout=600 I will eventually start seeing my previously attributed IP address instead of running out of IPs. Am I reading an old document that is outdated? Thank you very much, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130322/25dce4f4/attachment.html>