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 <miroslav.ma...@pantheon.tech> > 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 <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