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
