openstack team mailing list archive

[Nathanael Burton <nathanael.i.burton@xxxxxxxxx>]

On Mar 23, 2013 4:02 AM, "David Hill" <david.hill@xxxxxxxxxxx> wrote:
>
>
> ________________________________________
> 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> 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