[openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

Kevin Benton blak111 at gmail.com
Tue May 26 21:53:06 UTC 2015


>Actually, that approach was initially taken for bug 1345947, but then the
patch was abandoned to be replaced with a simpler - --dhcp-authoritative
approach that ended up with unexpected NAKs for multi agent setup.

>See: https://review.openstack.org/#/c/108272/12

So I had seen that patch but it's quite different from the approach I was
taking. That one requires a new script in the 'bin' directory, a new entry
in setup.cfg, an a new dhcp filter entry for rootwrap. Is that something
you would be comfortable back-porting all of the way back to Icehouse?

The approach I was using was to generate the script at runtime in the data
directory for each instance to just return the addresses directly. That way
there are no setup changes or new entries in bin. Personally, I felt it was
easier to understand since it simply generated a big echo statement, but I
might be biased because I wrote it. :)

It's really up to what you think is cleaner to back-port.

On Tue, May 26, 2015 at 6:57 AM, Ihar Hrachyshka <ihrachys at redhat.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/26/2015 04:35 AM, Kevin Benton 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.
> >
>
> Actually, that approach was initially taken for bug 1345947, but then
> the patch was abandoned to be replaced with a simpler
> - --dhcp-authoritative approach that ended up with unexpected NAKs for
> multi agent setup.
>
> See: https://review.openstack.org/#/c/108272/12
>
> Maybe we actually want to restore the work and merge it after
> conflicts are resolved and --dhcp-authoritative option is killed; the
> patch was almost merged when --dhcp-authoritative suggestion emerged,
> so most of nitpicking work should be complete now (though at the same
> time, I totally trust our community to find another pile of nits to
> work on for the next few weeks!)
>
> ===
>
> Speaking of regression testing... Are full stack tests already
> powerful enough for us to invoke multiple DHCP agents and test the
> scenario?
>
> Ihar
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8
> Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw
> u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u
> V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w
> 7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS
> 67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0=
> =xivW
> -----END PGP SIGNATURE-----
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150526/f241ee57/attachment.html>


More information about the OpenStack-dev mailing list