Option 4, turn off authoritative if we don’t want NAK’s? doug
> On May 25, 2015, at 7:35 PM, Kevin Benton <blak...@gmail.com> wrote: > > Hi, > > A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused > DHCPNAK messages when multiple agents are scheduled to a network [2]. > > This was back-ported to Icehouse and Juno so we need a fix that is compatible > with both of them. > > I have two fixes for this so far and a third alternative if we don't like > those. > > The first is hacky, but it's only a few-line change.[3] It adds an iptables > rule that just stops the DHCPNAKs from making it to the client. This is clean > to back-port but it doesn't protect clients that have filtering disabled > (e.g. bare metal). > > The second persists the DHCP leases to a database.[4] The downside to this > was always that being rescheduled to another agent would mean no entries in > the lease file. This approach adds a work-around to generate an initial fake > lease file based on all of the ports in the network. > > A third approach that I don't have a patch pushed for yet is very similar to > the second. When dnsmasq is in the leasefile-ro mode, it will call the script > passed to --dhcp-script to get a list of leases to start with. This script > would be built with the same logic as the second one. The only difference > between the second approach is that dnsmasq wouldn't persist leases to a > database. > > > I'm looking for feedback on how we want to go forward with this in a > back-port friendly manner. > > Cheers, > Kevin Benton > > > 1. > https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z > > <https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z> > 2. https://bugs.launchpad.net/neutron/+bug/1457900 > <https://bugs.launchpad.net/neutron/+bug/1457900> > 3. https://review.openstack.org/#/c/185332/ > <https://review.openstack.org/#/c/185332/> > 4. https://review.openstack.org/#/c/185486/ > <https://review.openstack.org/#/c/185486/> > > -- > Kevin Benton > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
