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.
On Oct 14, 2016, at 12:35 PM, Luis Gomez
As far as I can tell nothing we have done so far has helped l2switch test, it
is still failing.
On Oct 14, 2016, at 9:53 AM, Abhijit Kumbhare
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
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