openstack team mailing list archive

[David Hill <david.hill@xxxxxxxxxxx>]

________________________________________
From: Robert Collins [robertc@xxxxxxxxxxxxxxxxx]
Sent: March 23, 2013 02:21
To: David Hill
Cc: Kevin Stevens; openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] DHCP release

On 23 March 2013 14:53, David Hill <david.hill@xxxxxxxxxxx> 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