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<mailto: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<mailto: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<mailto: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-dev@lists.opendaylight.org<mailto:L2switch-dev@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

[logo]


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

[logo]


_______________________________________________
L2switch-dev mailing list
L2switch-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/l2switch-dev

Reply via email to