[ovs-dev] [PATCH v3] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build

[Numan Siddique]

On Thu, Nov 1, 2018, 5:18 AM Ben Pfaff <blp at ovn.org wrote:

> Thanks!
>
> On Wed, Oct 31, 2018 at 04:28:00PM -0700, Yifeng Sun wrote:
> > For the second question, if there is error reading /etc/resolv.conf,
> > currently we print a warning and continue trying to resolve names.
> > As you said, I will create a patch to let dns resolving fail for this
> case.
>

Please note that with the present code, resolver will block if
/etc/resolv.conf has "127.0.0.1" as the dns server.


>
> > Thanks,
> > Yifeng
> >
> > On Wed, Oct 31, 2018 at 3:59 PM Ben Pfaff <blp at ovn.org> wrote:
> >
> > > OK, that answers the first question.  What about if no DNS servers are
> > > available; what does the resolver do in that case?
> > >
> > > On Wed, Oct 31, 2018 at 03:24:13PM -0700, Yifeng Sun wrote:
> > > > Hi Ben,
> > > >
> > > > The dns resolving depends on libunbound's ub_resolve, which, from
> > > > Numan's experience as well as my reading on its documentation,
> > > > doesn't support timeout. I agree there is a bug and we should fix it.
> > > >
> > > > Thanks,
> > > > Yifeng
> > > >
> > > > On Wed, Oct 31, 2018 at 1:59 PM Ben Pfaff <blp at ovn.org> wrote:
> > > >
> > > > > On Thu, Oct 25, 2018 at 03:27:41PM +0530, nusiddiq at redhat.com
> wrote:
> > > > > > From: Numan Siddique <nusiddiq at redhat.com>
> > > > > >
> > > > > > When 'make check' is called by the mock rpm build (which disables
> > > > > networking),
> > > > > > the test "ovn-nbctl: LBs - daemon" fails when it runs the command
> > > > > > "ovn-nbctl lb-add lb0 30.0.0.1a 192.168.10.10:80,
> 192.168.10.20:80".
> > > > > ovn-nbctl
> > > > > > extracts the vip by calling the socket util function
> > > > > 'inet_parse_active()',
> > > > > > and this function blocks when libunbound function ub_resolve() is
> > > called
> > > > > > further down. ub_resolve() is a blocking function without
> timeout and
> > > > > all the
> > > > > > ovs/ovn utilities use this function.
> > > > > >
> > > > > > As reported by Timothy Redaelli, the issue can also be
> reproduced by
> > > > > running
> > > > > > the below commands
> > > > > >
> > > > > > $ sudo unshare -mn -- sh -c 'ip addr add dev lo 127.0.0.1 && \
> > > > > >   mount --bind /dev/null /etc/resolv.conf && runuser $SUDO_USER'
> > > > > > $ make sandbox SANDBOXFLAGS="--ovn"
> > > > > > $ ovn-nbctl -vsocket_util:off lb-add lb0 30.0.0.1a \
> > > > > >   192.168.10.10:80,192.168.10.20:80
> > > > > >
> > > > > > To address this issue, this patch adds a new function -
> > > > > inet_parse_ip_addr_and_port()
> > > > > > which expects IP:[port] address in the 'target_' argument and
> > > disables
> > > > > resolving
> > > > > > the host. This new function is now used in ovn-northd, ovn-nbctl
> and
> > > > > ovn-trace.
> > > > > > It is fine to use this function as load balancer VIP cannot be a
> > > > > hostname.
> > > > > >
> > > > > > Reported-by: Timothy Redaelli <tredaelli at redhat.com>
> > > > > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1641672
> > > > > > Tested-by: Timothy Redaelli <tredaelli at redhat.com>
> > > > > > Signed-off-by: Numan Siddique <nusiddiq at redhat.com>
> > > > >
> > > > > I have multiple thoughts here.
> > > > >
> > > > > First, if the resolver in OVS never times out, then that seems
> like a
> > > > > bug in the OVS resolver.  Yifeng, you wrote the DNS code.  Is it
> true
> > > > > that it never times out?  If so, should we fix that.
> > > > >
> > > > > Second, about the mock RPM build with disabled networking.  Does
> this
> > > > > environment have a /etc/resolv.conf that specifies a DNS server?
> If it
> > > > > does, then that seems like a bug in the build environment.  If it
> does
> > > > > not, then that seems like a bug in our DNS resolver code, because
> DNS
> > > > > resolution should immediately fail if no DNS servers are available.
> > > > >
> > > > > Third, again about naming.  If we are going to have two functions
> that
> > > > > act similarly, with the only difference being that one resolves DNS
> > > > > names and the other does not, then the naming should reflect that
> > > > > clearly.  It still isn't obvious to me with the new names.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Ben.
> > > > >
> > >
>