On Mar 23, 2013 4:02 AM, "David Hill" <david.h...@ubisoft.com> wrote: > > > ________________________________________ > From: Robert Collins [robe...@robertcollins.net] > Sent: March 23, 2013 02:21 > To: David Hill > Cc: Kevin Stevens; openstack@lists.launchpad.net > Subject: Re: [Openstack] DHCP release > > On 23 March 2013 14:53, David Hill <david.h...@ubisoft.com> wrote: > > 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? > > When you reuse an IP address you run the risk of other machines that > have the IP cached (e.g. as DNS lookup result, or because they were > configured to use it as a service endpoint) talking to the wrong > machine. The long timeout is to prevent the sort of confusing hard to > debug errors that that happen when machine A is replaced by machine C > on A's IP address. > > My 2c: just make your pool larger. Grab 10/8 and have 16M ip's to play with. > > -Rob > > I'm not the network guy here but, if I use a 10/8 and that we already have 10/8 in our internal network, this could easily become a problem.... am I wrong? > > Also, if a VM is deleted, IMHO, it's destroyed with all it's network. I don't know if this is "old minding" or anything, but when I destroy a VM in VSphere, I expect it to disappear leaving no trace. This is the cloud, and when I delete something, I expect it to simply be deleted. > > My 2c, but I see your point and have nothing against it. > > > 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
David, I believe the biggest reason for the long timeout is historical based on bugs in dnsmasq [1]. You can probably just use the default of 600 now if you're using a new enough version of dnsmasq. [1] - https://lists.launchpad.net/openstack/msg11696.html Thanks, Nate
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
