> On Oct 14, 2016, at 12:49 PM, Jamo Luhrsen <[email protected]> wrote: > > > > On 10/14/2016 12:37 PM, Luis Gomez wrote: >> >>> On Oct 14, 2016, at 9:18 AM, Jamo Luhrsen <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On 10/13/2016 09:50 PM, Luis Gomez wrote: >>>> Hi all, >>>> >>>> We are getting close to Boron SR1 so I think it makes sense to review the >>>> 2 blocking issues we have: >>>> >>>> >>>> 1) https://bugs.opendaylight.org/show_bug.cgi?id=6575 >>>> >>>> Summary: >>>> >>>> l2switch does not work well when mininet is disconnected and connected >>>> with no time in-between. >>>> >>>> Description: >>>> >>>> This is kind of old issue, since the He->Li migration the l2switch has >>>> experienced random issues in the system test: >>>> >>>> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-boron/ >>>> >>>> Same test passes fine in Beryllium as you can see below: >>>> >>>> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-beryllium/ >>>> >>>> The last discovery (just before Boron release) was that giving more time >>>> between stop mininet and start mininet made the >>>> suite pass. >>>> >>>> Criticality: >>>> >>>> Although this was a clear regression in l2switch test (Be->B), this bug >>>> was not initially marked as blocker because it was >>>> not trivial to reproduce (e.g. switch connection flap). >>>> >>>> Risk of not fixing: >>>> >>>> l2switch and other similar applications relying on ofplugin may not work >>>> well when switch connection flaps. >>> >>> >>> Luis, not that you have any spare cycles, but I wonder how reproducible >>> this issue would >>> be in the case of an entire network being unreachable for some period and >>> then all reconnecting >>> back at once. A test with iptables blocking 6633 on the controller until >>> all nodes are gone >>> from operational then flushing the rule would simulate that. >>> >>> This seems like a somewhat valid real world scenario which might make the >>> bug more important >>> to fix. >> >> So far it is only l2switch application (loop removal and address tracker to >> be more precise) that has issues with this switch >> quick disconnect-reconnect. I am not sure what you are asking here, trying >> with other OF apps? > > I'm asking if the problem exists (same l2switch app and ODL setup) when you > "isolate" the network > from the controller and bring it back. As opposed to the (probably assumed) > contrived fake automated > "mininet" up/down test. I'm coming from the angle of figuring out if this is > a regression that > could hit end users or just a CSIT regression that maybe is less priority to > fix.
AFAIK mininet up/down generates very "real" OVS operations, I can try with iptables or OVS commands (connect/disconnect channel) but I do not think that will change much. > > JamO > >>> >>> just a thought. >>> >>> JamO >>> >>> >>>> 2) https://bugs.opendaylight.org/show_bug.cgi?id=6917 >>>> >>>> Summary: >>>> >>>> Flow matching function (operational flow reconciliation) is not stable. >>>> >>>> Description: >>>> >>>> I discovered this issue doing some random flow push test in my laptop >>>> using POSTMAN: adding and deleting the same flow few >>>> times produced an alien ID in the operational flow. >>>> After that I have created a test that does exactly that: add flow, verify >>>> operational ID, delete flow, sleep 5s, repeat. >>>> With these simple steps the issue shows consistently for Boron (new test): >>>> >>>> https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-1node-flow-services-only-boron/758/archives/log.html.gz >>>> >>>> But not in Beryllium: >>>> >>>> https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-1node-flow-services-only-beryllium/1854/archives/log.html.gz >>>> >>>> Criticality: >>>> >>>> Besides the test regression, I think there are applications in ODL relying >>>> on operational flow ID that would be negatively >>>> impacted by this bug. >>>> >>>> Risk of not fixing: >>>> >>>> OF applications relying on operational flow ID (e.g. to confirm flows) can >>>> sporadically fail. >>>> >>>> >>>> _______________________________________________ >>>> L2switch-dev mailing list >>>> [email protected] >>>> <mailto:[email protected]> >>>> https://lists.opendaylight.org/mailman/listinfo/l2switch-dev >> _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
