<div dir="ltr">I have verified that the following fixes the issue for me locally: <a href="https://review.openstack.org/#/c/185486/">https://review.openstack.org/#/c/185486/</a><div>This works for rescheduled DHCP instances, multiple DHCP instances, and restarted DHCP instances.<br><div><br></div><div>I suspect that this is the cleanest thing to back-port because it doesn't add any translatables, scripts, rootwrap changes, or dependencies.</div><div><br></div><div>For more background, Brian brought this up the dnsmasq discussion email list and it seems like the DHCP client used by Cirros (udhcpc) honors the NAKs while other clients do not.[1] Apparently that client is being 'fixed' to ignore NAK's from other servers, which should effectively defeat the entire point of 'authoritative' DHCP servers. :)</div><div>However, we still need to fix this on our side since we can't tell people to just change their DHCP client.</div><div><br></div><div><br></div><div>1. <a href="http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q2/009570.html">http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q2/009570.html</a></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 3:02 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@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"><span class="">><span style="font-size:12.8000001907349px">As long as we confirm that the severity of this bug is accurately </span><span style="font-size:12.8000001907349px">represented in the bug report, then this is the first thing we should </span><span style="font-size:12.8000001907349px">do.  However, see below.  We tried this and did not encounter the </span><span style="font-size:12.8000001907349px">error in at least one experiment.  Are we sure that this is broken </span><span style="font-size:12.8000001907349px">everywhere multiple servers is used?  I'm checking internally to </span><span style="font-size:12.8000001907349px">confirm that we have run this successfully.</span><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">Outside of the reported bug, I had another person report this behavior to me from Big Switch Networks as well. Additionally, I was just informed today that it was encountered internally here at Mirantis testing the latest stable/juno code.</span></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, May 26, 2015 at 12:37 PM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, May 26, 2015 at 11:05 AM, Brian Haley <<a href="mailto:brian.haley@hp.com" target="_blank">brian.haley@hp.com</a>> wrote:<br>
> On 05/26/2015 01:12 PM, Salvatore Orlando wrote:<br>
>><br>
>>  From the bug Kevin reported it seems multiple dhcp agents per network<br>
>> have been<br>
>> completely broken by the fix for bug #1345947, so a revert of patch [1]<br>
>> (and<br>
>> stable backports) should probably be the first thing to do - if nothing<br>
>> else<br>
>> because the original bug has not nearly the same level of severity of the<br>
>> one it<br>
>> introduced.<br>
<br>
</span>As long as we confirm that the severity of this bug is accurately<br>
represented in the bug report, then this is the first thing we should<br>
do.  However, see below.  We tried this and did not encounter the<br>
error in at least one experiment.  Are we sure that this is broken<br>
everywhere multiple servers is used?  I'm checking internally to<br>
confirm that we have run this successfully.<br>
<span><br>
>> Before doing this however, I am wondering why the various instances of<br>
>> dnsmasq<br>
>> end up returning NAKs. I expect all instances to have the same hosts file,<br>
>> so<br>
>> they should be able to respond to DHCPDISCOVER/DHCPREQUEST correctly. Is<br>
>> the<br>
>> dnsmasq log telling us exactly why the authoritative setting is preventing<br>
>> us<br>
>> from doing so? (this is more of a curiosity in my side)<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/152080/" target="_blank">https://review.openstack.org/#/c/152080/</a><br>
<br>
</span>I also think we should understand more about this problem.  I think<br>
that understanding more specifics around the bug will help.  The<br>
details are a bit unclear to me.<br>
<span><br>
> In the original case, the DHCPREQUEST is for a renew, which is different<br>
> than for an initial request.  If the server does not have a lease entry<br>
> (which it won't after a restart), then it will NAK, which normally just<br>
> causes the client to retry at INIT state.<br>
><br>
> I had asked on the dnsmasq list about this [1], and the multiple server<br>
> question was the wildcard, my testing didn't see the error described in the<br>
> new bug though.  I guess the first proposed fix of re-populating the lease<br>
> information doesn't seem like such a bad idea any more, but I will reply to<br>
> my original query with the tcpdump information since I'm confused as to why<br>
> the second dhcp agent stepped-in with a NAK at all after originally offering<br>
> the same address as the first dhcp agent [2].<br>
<br>
</span>I remember being concerned about the multiple dnsmasq case.  I also<br>
remember having tried it and thought that it was working as expected.<br>
<span><br>
> I would agree the best thing to do is revert the stable backports while we<br>
> work on fixing this in the master branch.<br>
<br>
</span>I think we can propose the reverts but until we confirm the severity<br>
of this bug, I don't want them to merge.<br>
<span><font color="#888888"><br>
Carl<br>
</font></span><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>