I think it's very important not to make ovn-trace misleading. If my flow fails due to ACL drop or misconfigured NAT and ovn-trace shows that everything is fine, it'd make it pretty useless.
Ben, Thanks for the patch. I'll give it a go. On 1 December 2016 at 07:15, Ben Pfaff <[email protected]> wrote: > That seems like a reasonable way to start out. > > On Wed, Nov 30, 2016 at 08:40:27AM -0800, Guru Shetty wrote: > > ct_lb is tricky. I guess, the default should be to just pick the first > > option. > > > > On 30 November 2016 at 08:24, Ben Pfaff <[email protected]> wrote: > > > > > One initial, trivial, step might be to just have every ct_next respond > > > that the flow is established. Then at least it would be possible to > see > > > how packets flow through the system in the normal case. > > > > > > I noticed that you were getting DHCP-related errors from ovn-trace. I > > > have a patch out that fixes that: > > > https://patchwork.ozlabs.org/patch/685627/ > > > It hasn't attracted any reviews yet; I hope it does soon. > > > > > > On Wed, Nov 30, 2016 at 06:48:17AM +0000, Michael Kashin wrote: > > > > Sorry, replying to all now. > > > > > > > > I'm doing POC testing on a miniature OpenStack environment with a > single > > > > controller and two compute nodes. I want to be able to examine lflows > > > from > > > > any node (usually its the controller) to see the end-to-end datapath, > > > > including potential drops by ct ACLs, NAT and LB actions. Currently, > as > > > > I've said, I can only examine L2 flows. > > > > I can definitely see a benefit in doing the live flow debugging from > the > > > > operational standpoint. However, in my case, simply providing ct > metadata > > > > as command line options would be more than enough. > > > > Cheers, > > > > Michael > > > > > > > > On 30 Nov 2016 6:03 a.m., "Ben Pfaff" <[email protected]> wrote: > > > > > > > > > On Tue, Nov 29, 2016 at 08:20:50PM -0800, Justin Pettit wrote: > > > > > > > > > > > > > On Nov 29, 2016, at 5:28 PM, Ben Pfaff <[email protected]> wrote: > > > > > > > > > > > > > > It's "not yet". I'd like to implement them, but I'm not sure > how > > > to do > > > > > > > it because connection-tracking state, for any given > connection, is > > > > > > > embedded in the kernel of some hypervisor, which may not be one > > > that > > > > > > > ovn-trace is running on (if ovn-trace is even running on a > > > hypervisor). > > > > > > > > > > > > > > One option would be to supply connection-tracking metadata on > the > > > > > > > ovn-trace command line, e.g. something like --ct=est,rel or > > > --ct=new. > > > > > > > Then ct_next could simply set ct_state to the specified values. > > > This > > > > > > > would allow testing given scenarios. > > > > > > > > > > > > What about using the existing conntrack entries by running > > > "ovs-appctl > > > > > > dpctl/dump-conntrack" by default? That might be helpful for live > > > > > > debugging and seems like a reasonable default. It does seem > like it > > > > > > would be helpful to be able to specify values for testing what-if > > > > > > scenarios, too. I would imagine we'd need the ability to specify > > > > > > multiple zones on the command-line in case a single flow crosses > > > > > > multiple zones. > > > > > > > > > > I think our proposals cover two important special cases. > > > > > > > > > > Michael, what problem are you trying to solve? > > > > > > > > _______________________________________________ > > > discuss mailing list > > > [email protected] > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > >
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
