Open Stack

>As long as we confirm that the severity of this bug is accurately represented
in the bug report, then this is the first thing we should do.  However, see
below.  We tried this and did not encounter the error in at least one
experiment.  Are we sure that this is broken everywhere multiple servers is
used?  I'm checking internally to confirm that we have run this
successfully.

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.

On Tue, May 26, 2015 at 12:37 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:

> On Tue, May 26, 2015 at 11:05 AM, Brian Haley <brian.haley at hp.com> wrote:
> > On 05/26/2015 01:12 PM, Salvatore Orlando wrote:
> >>
> >>  From the bug Kevin reported it seems multiple dhcp agents per network
> >> have been
> >> completely broken by the fix for bug #1345947, so a revert of patch [1]
> >> (and
> >> stable backports) should probably be the first thing to do - if nothing
> >> else
> >> because the original bug has not nearly the same level of severity of
> the
> >> one it
> >> introduced.
>
> As long as we confirm that the severity of this bug is accurately
> represented in the bug report, then this is the first thing we should
> do.  However, see below.  We tried this and did not encounter the
> error in at least one experiment.  Are we sure that this is broken
> everywhere multiple servers is used?  I'm checking internally to
> confirm that we have run this successfully.
>
> >> Before doing this however, I am wondering why the various instances of
> >> dnsmasq
> >> end up returning NAKs. I expect all instances to have the same hosts
> file,
> >> so
> >> they should be able to respond to DHCPDISCOVER/DHCPREQUEST correctly. Is
> >> the
> >> dnsmasq log telling us exactly why the authoritative setting is
> preventing
> >> us
> >> from doing so? (this is more of a curiosity in my side)
> >>
> >> [1] https://review.openstack.org/#/c/152080/
>
> I also think we should understand more about this problem.  I think
> that understanding more specifics around the bug will help.  The
> details are a bit unclear to me.
>
> > In the original case, the DHCPREQUEST is for a renew, which is different
> > than for an initial request.  If the server does not have a lease entry
> > (which it won't after a restart), then it will NAK, which normally just
> > causes the client to retry at INIT state.
> >
> > I had asked on the dnsmasq list about this [1], and the multiple server
> > question was the wildcard, my testing didn't see the error described in
> the
> > new bug though.  I guess the first proposed fix of re-populating the
> lease
> > information doesn't seem like such a bad idea any more, but I will reply
> to
> > my original query with the tcpdump information since I'm confused as to
> why
> > the second dhcp agent stepped-in with a NAK at all after originally
> offering
> > the same address as the first dhcp agent [2].
>
> I remember being concerned about the multiple dnsmasq case.  I also
> remember having tried it and thought that it was working as expected.
>
> > I would agree the best thing to do is revert the stable backports while
> we
> > work on fixing this in the master branch.
>
> I think we can propose the reverts but until we confirm the severity
> of this bug, I don't want them to merge.
>
> Carl
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150526/60eb927c/attachment.html>