openstack team mailing list archive

[David Hill <david.hill@xxxxxxxxxxx>]

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.stevens@xxxxxxxxxxxxx]
Sent: March 22, 2013 18:01
To: David Hill; openstack@xxxxxxxxxxxxxxxxxxx
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.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