>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 <ihrac...@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-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
