Hello Kevin, Thanks for replying to my question. I was asking that question because if we go there: http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-vlan-networking.html and look at the very bottom of the page, it suggests the following:
# release leases immediately on terminate force_dhcp_release=true? (did I miss something?) # one week lease time dhcp_lease_time=604800 # two week disassociate timeout fixed_ip_disassociate_timeout=1209600 I tried that and if you have at some creation/destruction of virtual machines, let's say 2046 in the same week, you'll end up burning the 2046 IPs because they're never disassociated. At some point, nova-network complains with "no more fixed IP are available". Changing fixed_ip_disassociate_timeout to something smaller solves this issue. Is there any reasons why fixed_ip_disassociate_timeout should be bigger than dhcp_lease_time? Also, I thought that by destroying a virtual machine, it would release/disassociate the IP from the UUID since it has been destroyed (DELETED). I've turned on the debugging and with fixed_ip_disassociate_timeout set to 600 seocnds, it disassociate stale IPs after they've been deleted for at least 600 seconds. Is it a bug in our setup/nova-network or nova-network/manage relies on the periodic task that disassociate stale IPs in order to regain those IPs? Finaly, wouldn't it be better to simply disassociate a released IP as soon as the VM is deleted? Since we deleted the VM, why keep it in the database? Thank you very much, Dave ________________________________________ From: Kevin Stevens [kevin.stev...@rackspace.com] Sent: March 22, 2013 18:01 To: David Hill; openstack@lists.launchpad.net Subject: Re: [Openstack] DHCP release 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
