-----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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
