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
