I guess I had in mind that OVS_RESOLV_CONF would point to an alternate file to be used instead of /etc/resolve.conf.
On Fri, Nov 02, 2018 at 02:51:19PM -0700, Yifeng Sun wrote: > 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 <[email protected]> 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. > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
