About 6917, I have updated the bug with my observations.
Tried it about 23 times(add/get/del) in successions of 5 secs(used a stopwatch)
but could see the alien flow id in oper DS only once, and that too the moment I
tried a re-get it vanished.
I did use a different flow object, but I donot think that should cause any
In any case I will retry with the one mentioned in the original problem
description and then revert back
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Abhijit
Sent: Friday, October 14, 2016 10:24 PM
To: Luis Gomez
Cc: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
Subject: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis
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
We are getting close to Boron SR1 so I think it makes sense to review the 2
blocking issues we have:
l2switch does not work well when mininet is disconnected and connected with no
This is kind of old issue, since the He->Li migration the l2switch has
experienced random issues in the system test:
Same test passes fine in Beryllium as you can see below:
The last discovery (just before Boron release) was that giving more time
between stop mininet and start mininet made the suite pass.
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.
Flow matching function (operational flow reconciliation) is not stable.
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):
But not in Beryllium:
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
L2switch-dev mailing list
openflowplugin-dev mailing list