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
