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]
_______________________________________________ L2switch-dev mailing list L2switch-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/l2switch-dev
