Open Stack

>From the bug Kevin reported it seems multiple dhcp agents per network have
been completely broken by the fix for bug #1345947, so a revert of patch
[1] (and stable backports) should probably be the first thing to do - if
nothing else because the original bug has not nearly the same level of
severity of the one it introduced.
Before doing this however, I am wondering why the various instances of
dnsmasq end up returning NAKs. I expect all instances to have the same
hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST
correctly. Is the dnsmasq log telling us exactly why the authoritative
setting is preventing us from doing so? (this is more of a curiosity in my
side)

[1] https://review.openstack.org/#/c/152080/



On 26 May 2015 at 06:57, 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!)
>

That was my thought as well.
However, we should check whether that patch is ok to backport. For instance
I see what it appears to be adding a script:

[2]
https://review.openstack.org/#/c/108272/12/bin/neutron-dhcp-agent-dnsmasq-lease-init


>
> ===
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150526/e0f33d3d/attachment.html>