openstack team mailing list archive

[Kevin Stevens <kevin.stevens@xxxxxxxxxxxxx>]

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@xxxxxxxxxxx<mailto:david.hill@xxxxxxxxxxx>>
Date: Friday, March 22, 2013 12:59 PM
To: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
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