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.h...@ubisoft.com<mailto:david.h...@ubisoft.com>> Date: Friday, March 22, 2013 12:59 PM To: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>" <openstack@lists.launchpad.net<mailto:openstack@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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
