On Thu, Apr 18, 2013 at 09:46:30AM -0700, Justin Pettit wrote: > On Apr 18, 2013, at 9:28 AM, Ben Pfaff <b...@nicira.com> wrote: > > > But I'm not sure about the test. It tries to connect to the default > > OpenFlow port on localhost. I guess that there will ordinarily be no > > OpenFlow controller listening there. Does the test still pass if there > > is, though? And assuming that it does, do we think that it is OK to do > > that in the unit tests? It could at least surprise the administrator of > > that controller, if there is one. > > Do you have a better suggestion? All the hidden flows I see are based > on a controller being set.
One way would be to start an ovs-controller process and then set the switch to connect to it. You'd probably want to tell the controller to listen on ptcp:0:127.0.0.1 and then check the log to find out what port it's really listening on. There are examples of this in the series that I posted on April 3 starting here: http://openvswitch.org/pipermail/dev/2013-April/026432.html > > Also, I spent some time staring at the code that generates the second > > version of expout in the test. I couldn't figure out what actually > > changes. What is the difference between the pre-"set-controller" and > > post-"set-controller" output of "dump-tables"? > > Nothing changes, which is the point. [...] So why is there a bunch of code to edit expout then? That's the part that's confusing. If it's not changing anything then you can just delete all this code: +# Check that the configuration was updated. +mv expout orig-expout +(echo "OFPST_TABLE reply (xid=0x2): 254 tables + 0: classifier: wild=0x3fffff, max=1000000, active=0 + lookup=0, matched=0 + 1: table1 : wild=0x3fffff, max=1000000, active=0 + lookup=0, matched=0" + tail -n +6 orig-expout) > expout _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
