Actually this is the drop flow so it is expected, anyway going deeper into l2switch test issues I see:
- The address tracker issue is because hosts addresses are not getting cleared when we restart mininet with no sleep in-between. - The loop remover issue could be related to some test issue, I am trying to clean up/repair the test here: https://git.opendaylight.org/gerrit/#/c/47095/ BR/Luis > On Oct 18, 2016, at 10:02 AM, Luis Gomez <[email protected]> wrote: > > There are definitely weird things going on in l2switch, the first ERROR you > mention produces some weird flow (no match and no action) in the switch: > > Flow 55: > "cookie": 3098476543630901303, > "flags": "", > "hard-timeout": 0, > "id": "55", > "idle-timeout": 0, > "match": {}, > "opendaylight-flow-statistics:flow-statistics": { > "byte-count": 0, > "duration": { > "nanosecond": 239000000, > "second": 36 > }, > "packet-count": 0 > }, > "priority": 0, > "table_id": 0 > > > The second issue, I am not sure what is the impact but definitely something > to look at. > > I think in general we will need l2switch support to troubleshoot and progress > in current issues. > > BR/Luis > > >> On Oct 17, 2016, at 8:09 AM, Miroslav Macko <[email protected]> >> wrote: >> >> Hello Luis and dev guys, >> >> There is this info from l2-switch in the karaf log: >> >> 2016-10-14 22:43:24,941 | INFO | pool-16-thread-1 | FlowWriterServiceImpl >> | 229 - org.opendaylight.l2switch.main.impl - 0.5.0.SNAPSHOT | In >> addMacToMacFlowsUsingShortestPath: No flows added. Source and Destination >> ports are same. >> >> Is it ok? >> >> And this debug message(it has incorrect severity): >> >> 2016-10-14 22:43:55,282 | ERROR | entLoopGroup-5-3 | DeviceFlowRegistryImpl >> | 210 - org.opendaylight.openflowplugin.impl - 0.4.0.SNAPSHOT | >> Flow with flowId 85 already exists in table 0 >> >> So it looks like that flows with the same ID are added. >> >> What in short these failing tests are doing and what it should test please? >> >> Thanks, >> Miro >> >> ________________________________________ >> Od: Luis Gomez <[email protected]> >> Odoslané: 15. októbra 2016 1:01 >> Komu: Tomáš Slušný >> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev >> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis >> >> No luck :), still fails on "address tracker" and "loop remover": >> >> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/154/ >> https://logs.opendaylight.org/releng/jenkins092/l2switch-csit-1node-switch-only-carbon/154/archives/log.html.gz >> >> BR/Luis >> >> >>> On Oct 14, 2016, at 2:26 PM, Luis Gomez <[email protected]> wrote: >>> >>> OK Tomas, I will try your patch >>> https://git.opendaylight.org/gerrit/#/c/46390/ on >>> l2switch-csit-1node-switch-only-carbon and let you know. >>> >>> >>>> On Oct 14, 2016, at 1:23 PM, Tomáš Slušný <[email protected]> >>>> wrote: >>>> >>>> Also, 6710 was already merged only in master branch, but not yet in boron. >>>> It have cherry-pick ready here: >>>> https://git.opendaylight.org/gerrit/#/c/46761/, but until it is merged, I >>>> think it would be better to check for improvement in Jenkins test for >>>> Carbon here: >>>> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/ >>>> Od: Tomáš Slušný <[email protected]> >>>> Odoslané: 14. októbra 2016 22:13 >>>> Komu: Luis Gomez; Abhijit Kumbhare >>>> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev >>>> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis >>>> >>>> 6710 was related to both cluster and single node, because even in single >>>> node scenario, we are registering to ClusterSingletonService, what had >>>> problems when we tried to re-register, when we do not fully closed >>>> previous registration (so, when we disconnected and reconnected too fast). >>>> Most part of this fix was done in bug 6710, but part of it had to be done >>>> also in openflowplugin side in this gerrit patch: >>>> https://git.opendaylight.org/gerrit/#/c/46390/. So, Luis, is it possible >>>> to run failing l2switch test on that patch and see, if it solves anything, >>>> or not? >>>> >>>> Od: Luis Gomez <[email protected]> >>>> Odoslané: 14. októbra 2016 21:49 >>>> Komu: Abhijit Kumbhare >>>> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev >>>> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis >>>> >>>> Well I think if openflowplugin people cannot figure out where the issue >>>> is, the next would be to get some debug and further analysis from l2switch >>>> people explaining the application miss-behavior. >>>> >>>> If there are no people available in l2switch to do this, we can lower the >>>> priority to major or critical. >>>> >>>> BR/Luis >>>> >>>> >>>>> On Oct 14, 2016, at 12:35 PM, Luis Gomez <[email protected]> wrote: >>>>> >>>>> As far as I can tell nothing we have done so far has helped l2switch >>>>> test, it is still failing. >>>>> >>>>> BR/Luis >>>>> >>>>>> On Oct 14, 2016, at 9:53 AM, Abhijit Kumbhare <[email protected]> >>>>>> wrote: >>>>>> >>>>>> About the first one - https://bugs.opendaylight.org/show_bug.cgi?id=6575: >>>>>> >>>>>> Tomas has said in yesterday's meeting that this was dependent on >>>>>> https://bugs.opendaylight.org/show_bug.cgi?id=6710. And that it was >>>>>> fixed. Can we retest? Also a question for Tomas: 6710 is cluster related >>>>>> - while 6575 is not clear if it is cluster or single node. Are we sure >>>>>> 6575 is fixed? >>>>>> >>>>>> The second one: https://bugs.opendaylight.org/show_bug.cgi?id=6917 - >>>>>> Shuva will respond about that some time. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 13, 2016 at 9:50 PM, Luis Gomez <[email protected]> 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. >>>>>> >>>>>> >>>>>> 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] >>>>>> https://lists.opendaylight.org/mailman/listinfo/l2switch-dev >>>>>> >>>>> >>>> >>>> TomášSlušný >>>> Software Developer >>>> >>>> Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >>>> R&D centrum / Janka Kráľa 9 / 974 01 Banská Bystrica / Slovakia >>>> +421 911 083 902 / [email protected] >>>> reception: +421 2 206 65 114 / www.pantheon.sk >>>> >>>> >>>> TomášSlušný >>>> Software Developer >>>> >>>> Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >>>> R&D centrum / Janka Kráľa 9 / 974 01 Banská Bystrica / Slovakia >>>> +421 911 083 902 / [email protected] >>>> reception: +421 2 206 65 114 / www.pantheon.sk >>>> >>>> >>> >> >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> MiroslavMacko >> Software Developer >> >> Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >> R&D centrum / Janka Kráľa 9 / 974 01 Banská Bystrica / Slovakia >> / [email protected] >> reception: +421 2 206 65 114 / www.pantheon.sk >> >> [logo] >> >> > _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
