<div dir="ltr">><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><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"><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 class="">On Tue, May 26, 2015 at 11:05 AM, Brian Haley <<a href="mailto:brian.haley@hp.com">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 class=""><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 class=""><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 class=""><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 class="HOEnZb"><font color="#888888"><br>
Carl<br>
</font></span><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>