<p dir="ltr">Sorry, replying to all now.</p>
<p dir="ltr">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.<br>
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.<br>
Cheers,<br>
Michael</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 30 Nov 2016 6:03 a.m., "Ben Pfaff" <<a href="mailto:blp@ovn.org">blp@ovn.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Nov 29, 2016 at 08:20:50PM -0800, Justin Pettit wrote:<br>
><br>
> > On Nov 29, 2016, at 5:28 PM, Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>> wrote:<br>
> ><br>
> > It's "not yet". I'd like to implement them, but I'm not sure how to do<br>
> > it because connection-tracking state, for any given connection, is<br>
> > embedded in the kernel of some hypervisor, which may not be one that<br>
> > ovn-trace is running on (if ovn-trace is even running on a hypervisor).<br>
> ><br>
> > One option would be to supply connection-tracking metadata on the<br>
> > ovn-trace command line, e.g. something like --ct=est,rel or --ct=new.<br>
> > Then ct_next could simply set ct_state to the specified values. This<br>
> > would allow testing given scenarios.<br>
><br>
> What about using the existing conntrack entries by running "ovs-appctl<br>
> dpctl/dump-conntrack" by default? That might be helpful for live<br>
> debugging and seems like a reasonable default. It does seem like it<br>
> would be helpful to be able to specify values for testing what-if<br>
> scenarios, too. I would imagine we'd need the ability to specify<br>
> multiple zones on the command-line in case a single flow crosses<br>
> multiple zones.<br>
<br>
I think our proposals cover two important special cases.<br>
<br>
Michael, what problem are you trying to solve?<br>
</blockquote></div></div>