<div dir="ltr">><span style="font-size:12.8000001907349px">Actually, that approach was initially taken for bug 1345947, but then </span><span style="font-size:12.8000001907349px">the patch was abandoned to be replaced with a simpler </span><span style="font-size:12.8000001907349px">- --dhcp-authoritative approach that ended up with unexpected NAKs for </span><span style="font-size:12.8000001907349px">multi agent setup.</span><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>See: </span><a href="https://review.openstack.org/#/c/108272/12" target="_blank" style="font-size:12.8000001907349px">https://review.openstack.org/#/c/108272/12</a><div><br></div><div>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?<br></div><div><br></div><div>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. :)</div><div><br></div><div>It's really up to what you think is cleaner to back-port.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 6:57 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<span class=""><br>
On 05/26/2015 04:35 AM, Kevin Benton wrote:<br>
> Hi,<br>
><br>
> A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has<br>
> caused DHCPNAK messages when multiple agents are scheduled to a<br>
> network [2].<br>
><br>
> This was back-ported to Icehouse and Juno so we need a fix that is<br>
> compatible with both of them.<br>
><br>
> I have two fixes for this so far and a third alternative if we<br>
> don't like those.<br>
><br>
> The first is hacky, but it's only a few-line change.[3] It adds an<br>
> iptables rule that just stops the DHCPNAKs from making it to the<br>
> client. This is clean to back-port but it doesn't protect clients<br>
> that have filtering disabled (e.g. bare metal).<br>
><br>
> The second persists the DHCP leases to a database.[4] The downside<br>
> to this was always that being rescheduled to another agent would<br>
> mean no entries in the lease file. This approach adds a work-around<br>
> to generate an initial fake lease file based on all of the ports in<br>
> the network.<br>
><br>
> A third approach that I don't have a patch pushed for yet is very<br>
> similar to the second. When dnsmasq is in the leasefile-ro mode, it<br>
> will call the script passed to --dhcp-script to get a list of<br>
> leases to start with. This script would be built with the same<br>
> logic as the second one. The only difference between the second<br>
> approach is that dnsmasq wouldn't persist leases to a database.<br>
><br>
<br>
</span>Actually, that approach was initially taken for bug 1345947, but then<br>
the patch was abandoned to be replaced with a simpler<br>
- --dhcp-authoritative approach that ended up with unexpected NAKs for<br>
multi agent setup.<br>
<br>
See: <a href="https://review.openstack.org/#/c/108272/12" target="_blank">https://review.openstack.org/#/c/108272/12</a><br>
<br>
Maybe we actually want to restore the work and merge it after<br>
conflicts are resolved and --dhcp-authoritative option is killed; the<br>
patch was almost merged when --dhcp-authoritative suggestion emerged,<br>
so most of nitpicking work should be complete now (though at the same<br>
time, I totally trust our community to find another pile of nits to<br>
work on for the next few weeks!)<br>
<br>
===<br>
<br>
Speaking of regression testing... Are full stack tests already<br>
powerful enough for us to invoke multiple DHCP agents and test the<br>
scenario?<br>
<br>
Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8<br>
Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw<br>
u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u<br>
V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w<br>
7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS<br>
67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0=<br>
=xivW<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>