Numan Siddique <nusid...@redhat.com> wrote on 08/23/2016 07:49:52 AM:
> From: Numan Siddique <nusid...@redhat.com> > To: Flavio Fernandes <fla...@flaviof.com> > Cc: b...@openvswitch.org, Gurucharan Shetty <g...@ovn.org>, Ben > Pfaff <b...@ovn.org>, Ryan Moats/Omaha/IBM@IBMUS > Date: 08/23/2016 07:50 AM > Subject: Re: ovn: OF rules for datapath not getting removed upon ls-del > > On Tue, Aug 23, 2016 at 7:31 AM, Flavio Fernandes <fla...@flaviof.com> wrote: > > On Aug 22, 2016, at 4:32 PM, Flavio Fernandes <fla...@flaviof.com> wrote: > > [cc: Numan and Guru, Ben, Ryan] > > Hi folks, > > I've been chasing an issue in that OF rules are not properly cleaned > up when I remove the datapath that is > associated with a logical switch. The smallest/dumb test I could > come up with looks like this: > > It occurred to me that I may have done a really lousy job in > demonstrating the issue, due to the > confusing output. Sorry about that! > > Instead of getting confused, please consider the following unit test > in order to reproduce this: > > http://openvswitch.org/pipermail/dev/2016-August/078431.html > > Thanks, > > -- flavio > > 1) start OVS sandbox (cd ./utilities && rm -rf ./sandbox && ./ovs-sim) > 2) ovn_start, net_add ... create hv1 > 3) as hv1, create ovs port to be bound to lsp 'foo' > 4) ls-add sw0 > 5) lsp-add port 'foo' > 6) undo 3 (ovs port create) > 7) undo 5 (lsp create) > 8) undo 4 (ls create) > 9) look at output of "OF flows" and verify that there is no > mentioning of metadata=0x1 anywhere > > The exact test steps are here [testSteps]. > > For the output of a 'good' run, look here [goodRun]. > For the output of a 'bad' run, look here [badRun]. > > Using git bisect, I determined that the issue was very likely > introduced here [issueStart]. > > All in all, I would very much appreciate if: > > 1) any of you guys "see" the same, and agree this is an issue; > 2) know if the changes for "reset flow processing" could be improved > so these rules stop 'leaking'. > > I suspect there may be other issues, but I figure we start here and > work our way up to the > commits in 2.6. > > Thank you! > > -- flaviof > > [testSteps]: https://gist.github.com/de0bf9e1211267f1afd547aad6072c69 > [goodRun]: https://gist.github.com/0afeac5b75a0ef6bf015d6868a12a3cd > [badRun]: https://gist.github.com/67cfca69abf8ccba1c57b4a5ff08a94e > > [issueStart]: > f5792c3f36dee70f5c17d03982dce212847024b3 is the first bad commit > commit f5792c3f36dee70f5c17d03982dce212847024b3 > Author: Numan Siddique <nusid...@redhat.com> > Date: Thu Aug 11 17:51:39 2016 +0530 > > ovn-controller: Reset flow processing after (re)connection to switch > > When ovn-controller reconnects to the ovs-vswitchd, it deletes all the > OF flows in the switch. It doesn't install the flows again, leaving > the datapath broken unless ovn-controller is restarted or ovn-northd > updates the SB DB. > > The reason for this is > - lflow_reset_processing() is not called after the reconnection > - the hmap "installed_flows" is not cleared, because of which > ofctrl_put skips adding the flows to the switch. > > This patch fixes the issue and also adds a test case to test > this scenario. > > Signed-off-by: Numan Siddique <nusid...@redhat.com> > Signed-off-by: Ben Pfaff <b...@ovn.org> > Acked-by: Ryan Moats <rmo...@us.ibm.com> > > :040000 040000 3687d0bb43c69133c7709f6b22315060354c7253 > d5da3e29f654a92acf58fcd215366b5aeb53aef6 M ovn > :040000 040000 caf406231eba7541aab62c6bda301f22256e7c76 > 18f08e67bb4087ea6d05f59356802ef75bc0de81 M tests > > Hi Flavio, > > I am able to reproduce the issue. And with the below commands run in > the sandbox, none of the OF flows are getting deleted. > > ------------ > ovn-nbctl ls-add ls1 > ovn-nbctl lsp-add ls1 lp1 > ovn-nbctl lsp-set-addresses lp1 unknown > ovs-vsctl add-port br-int vif1 -- set Interface vif1 external-ids:iface-id=lp1 > > sleep 1 > ovs-ofctl dump-flows br-int > > ovn-nbctl lsp-set-addresses lp1 > ovn-nbctl lsp-del lp1 > ovn-nbctl ls-del ls1 > > sleep 1 > ovs-ofctl dump-flows br-int > ------------ > > It works fine if the commit " > f5792c3f36dee70f5c17d03982dce212847024b3" is reverted or if I apply > this patch from Ryan > https://patchwork.ozlabs.org/patch/661159/ > Which I also just said in a comment on the patch set on dev. What's the chances of moving 661159 up in the review queue? Ryan
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
