<div dir="ltr">Thanks! I'll <span style="color:rgb(50,50,50);white-space:nowrap;font-family:Arial,宋体,微软雅黑;font-size:14px;line-height:16px">reconsider about this.</span></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-01 16:54 GMT+08:00 Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><span style="font-size:12.8000001907349px">>But I don't know that does NAK matters?</span><br><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">Yes, some clients will honor it and re-request, so they end up in a loop. I believe the dhcp client in the Cirros image does this.</span></div><span class=""><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:14px">"dhcp-authoritative" is really a simple way to solve the problem of that dnsmasq will lose lease if restarted</span></div><div><span style="font-size:14px"><br></span></div></span><div><span style="font-size:14px">Yes, unfortunately it made dnsmasq behave authoritatively though. :-) The patch that merged should fix the NAK issue and the lease lost on restart issue.</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 1:47 AM, Damon Wang <span dir="ltr"><<a href="mailto:damon.devops@gmail.com" target="_blank">damon.devops@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Benton,<div><br></div><div>I'm sorry that seems I missed your discuss. I just seen your patch's merge yesterday.</div><div><br></div><div>But I don't know that does NAK matters? A client will get a ACK and a NAK if there are two agents, it's ok because client will assign IP address successfully according to the ACK.</div><div><br></div><div><span style="font-size:14px">"dhcp-authoritative" is really a simple way to solve the problem of that dnsmasq will lose lease if restarted, and we have put this patch to our production (public cloud), it works well.</span><br></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Thanks!</span></div><div><span style="font-size:14px">Wei</span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-28 6:39 GMT+08:00 Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>><span style="font-size:12.8000001907349px">Looking at [1], I don't see that it generates a script at all. What it </span><span style="font-size:12.8000001907349px">does is it prepopulates a lease file for dnsmasq consumption (so there </span><span style="font-size:12.8000001907349px">is no external shell involved). Do we talk about the same patch?</span><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">Not that patch. In the first email, I mentioned 3 approaches: iptables, lease db generation, and script generation. I didn't put something up for script generation because it was basically the same thing is the lease db generation with an echo statement at the top.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I was just pointing out that the script approach I was using was suggesting was quite different from the other one up for review. But it doesn't really matter because the lease DB is the easy way to go.</span></div><div><br></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Wed, May 27, 2015 at 4: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"><span>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
</span><span>On 05/26/2015 11:53 PM, Kevin Benton wrote:<br>
>> Actually, that approach was initially taken for bug 1345947, but<br>
> then the patch was abandoned to be replaced with a simpler -<br>
> --dhcp-authoritative approach that ended up with unexpected NAKs<br>
> for 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>
> So I had seen that patch but it's quite different from the approach<br>
> I was taking. That one requires a new script in the 'bin'<br>
> directory, a new entry in setup.cfg, an a new dhcp filter entry for<br>
> rootwrap. Is that something you would be comfortable back-porting<br>
> all of the way back to Icehouse?<br>
<br>
</span>I agree that a patch without a new script and, more importantly,<br>
without a rootwrap filter modification, is a lot better than the one I<br>
cited above.<br>
<span><br>
><br>
> The approach I was using was to generate the script at runtime in<br>
> the data directory for each instance to just return the addresses<br>
> directly. That way there are no setup changes or new entries in<br>
> bin. Personally, I felt it was easier to understand since it simply<br>
> generated a big echo statement, but I might be biased because I<br>
> wrote it. :)<br>
><br>
<br>
</span>Looking at [1], I don't see that it generates a script at all. What it<br>
does is it prepopulates a lease file for dnsmasq consumption (so there<br>
is no external shell involved). Do we talk about the same patch?<br>
<br>
I've checked [1], and it seems like the best approach, both from code<br>
complexity and "backportability" perspective. I've left some comments<br>
there.<br>
<br>
[1]: <a href="https://review.openstack.org/#/c/185486/" target="_blank">https://review.openstack.org/#/c/185486/</a><br>
<span><br>
Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
</span>iQEcBAEBCAAGBQJVZbE8AAoJEC5aWaUY1u57ufkH/RfsQJy+Ddz3f+L37mNY28uj<br>
h+gLaiJIcZ1iMKKMo1tpg881u/aKpy3LlScoKHLnwWXub/IPxrxN2+/IMfCoF9iV<br>
ZbgtmggVRh/TjHOMbMpQVqJ+J8qe4TN29kW5x1RcUEecYy/hbyyKeBYoLlEXoZhn<br>
GzWcWyx9yp2qSOqe9010K+nmXdAzD+jg8/YJlBtP/ggO0qoWB7Is/D2bHkoeCPsd<br>
uqJzhAAZg4w2hhPgKpb1aUhyQU9uE5gzj5Yh5PE+kvINDRwLTLoqWQ7sxpR1hiqH<br>
rZ8t8FE1wmdQKEWrsRVy6/2pLOziKVNGPinBLYwwBUGY+S7kb2Jc6AgAHrAx/iY=<br>
=Wnx+<br>
<div><div>-----END PGP SIGNATURE-----<br>
<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></div></div><span><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></div>
<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>
<br></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div>Kevin Benton</div></div>
</div>
</div></div><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>
<br></blockquote></div><br></div>