<p dir="ltr">On Mar 23, 2013 4:02 AM, "David Hill" <<a href="mailto:david.hill@ubisoft.com">david.hill@ubisoft.com</a>> wrote:<br>
><br>
><br>
> ________________________________________<br>
> From: Robert Collins [<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>]<br>
> Sent: March 23, 2013 02:21<br>
> To: David Hill<br>
> Cc: Kevin Stevens; <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Subject: Re: [Openstack] DHCP release<br>
><br>
> On 23 March 2013 14:53, David Hill <<a href="mailto:david.hill@ubisoft.com">david.hill@ubisoft.com</a>> wrote:<br>
> > Hello Kevin,<br>
> ><br>
> > Thanks for replying to my question. I was asking that question because if we go there: <a href="http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-vlan-networking.html">http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-vlan-networking.html</a> and look at the very bottom of the page, it suggests the following:<br>
> ><br>
> > # release leases immediately on terminate<br>
> > force_dhcp_release=true? (did I miss something?)<br>
> > # one week lease time<br>
> > dhcp_lease_time=604800<br>
> > # two week disassociate timeout<br>
> > fixed_ip_disassociate_timeout=1209600<br>
> ><br>
> > 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.<br>
> > Is there any reasons why fixed_ip_disassociate_timeout should be bigger than dhcp_lease_time?<br>
> ><br>
> > 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?<br>
> ><br>
> > 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?<br>
><br>
> When you reuse an IP address you run the risk of other machines that<br>
> have the IP cached (e.g. as DNS lookup result, or because they were<br>
> configured to use it as a service endpoint) talking to the wrong<br>
> machine. The long timeout is to prevent the sort of confusing hard to<br>
> debug errors that that happen when machine A is replaced by machine C<br>
> on A's IP address.<br>
><br>
> My 2c: just make your pool larger. Grab 10/8 and have 16M ip's to play with.<br>
><br>
> -Rob<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
> My 2c, but I see your point and have nothing against it.<br>
><br>
><br>
> Dave<br>
><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a></p>
<p dir="ltr">David,</p>
<p dir="ltr">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.</p>
<p dir="ltr">[1] - <a href="https://lists.launchpad.net/openstack/msg11696.html">https://lists.launchpad.net/openstack/msg11696.html</a></p>
<p dir="ltr">Thanks,</p>
<p dir="ltr">Nate</p>