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

Yifeng Sun pkusunyifeng at gmail.com
Fri Nov 2 21:51:19 UTC 2018


Hi Ben,

Based on the discussion, I am going to create a dns_resolve_timeout__
specifically for
sandboxing and testing. In runtime, dns resolving will check the
environment variable,
say OVS_RESOLV_CONF, to decide whether or not to use the timeout version of
actual
dns resolution. Does this sound good to you?

Thanks,
Yifeng

On Fri, Nov 2, 2018 at 1:21 PM Ben Pfaff <blp at ovn.org> wrote:

> On Fri, Nov 02, 2018 at 04:05:13PM -0400, Mark Michelson wrote:
> > On 11/01/2018 02:15 PM, Yifeng Sun wrote:
> > >Hi Mark,
> > >
> > >Thanks a lot for the information, that is very helpful.
> > >
> > > From your comments, I understand that we should keep the current
> > >DNS resolving behavior as is. The thing we need to improve is to
> > >stop resolving if there is no /etc/resolv.conf configured.
> > >
> > >And if /etc/resolv.conf exists and has "127.0.0.1" as the dns server,
> > >like Numan mentioned, resolver will block. For testing, I feel that a
> > >timeout dns_resolve makes sense. Can we determine testing
> > >context in runtime?
> >
> > I'm not sure about that. After thinking about this a bit more, it may
> > actually make more sense to use a sandboxed resolv.conf during our tests.
> > This way, we have control over what servers are configured and what
> timeouts
> > are. I'm not sure exactly how to achieve this, but it seems like a more
> > ideal option than changing the underlying code for tests.
>
> We use OVS_* environment variables for sandboxing other things, we could
> have an OVS_RESOLV_CONF variable I guess.
>


More information about the dev mailing list