Hi guys,
I've found what the problem is...
1) nova-dhcpbridge wasn't configured
2) The version provided with redhat seems to be buggy and I created a bug
report: https://bugzilla.redhat.com/show_bug.cgi?id=927349
With the provided version, dhcp-script is called only once at dnsmasq startup
and never at IP ack/release.
I've found a package (dnsmasq-2.62-1.el6.rfx.x86_64.rpm) that is more recent
and everything is behaving as expected.
Dave
From: Nathanael Burton [mailto:nathanael.i.bur...@gmail.com]
Sent: March-23-13 4:15 PM
To: David Hill
Cc: openstack@lists.launchpad.net; Robert Collins
Subject: Re: [Openstack] DHCP release
On Mar 23, 2013 4:02 AM, "David Hill"
<david.h...@ubisoft.com<mailto:david.h...@ubisoft.com>> wrote:
>
>
> ________________________________________
> From: Robert Collins
> [robe...@robertcollins.net<mailto:robe...@robertcollins.net>]
> Sent: March 23, 2013 02:21
> To: David Hill
> Cc: Kevin Stevens;
> openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
> Subject: Re: [Openstack] DHCP release
>
> On 23 March 2013 14:53, David Hill
> <david.h...@ubisoft.com<mailto: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<mailto: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
