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 <ece...@gmail.com> 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 <ece...@gmail.com> 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ý <tomas.slu...@pantheon.tech> 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ý <tomas.slu...@pantheon.tech> >> 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 <ece...@gmail.com> >> 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 <ece...@gmail.com> 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 <abhijitk...@gmail.com> >>>> 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 <ece...@gmail.com> 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 >>>> l2switch-...@lists.opendaylight.org >>>> 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 / tomas.slu...@pantheon.tech >> 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 / tomas.slu...@pantheon.tech >> reception: +421 2 206 65 114 / www.pantheon.sk >> >> > _______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org 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 / miroslav.ma...@pantheon.tech reception: +421 2 206 65 114 / www.pantheon.sk [logo] _______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev