On 10/13/2016 09:50 PM, Luis Gomez 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.


Luis,  not that you have any spare cycles, but I wonder how reproducible this 
issue would
be in the case of an entire network being unreachable for some period and then 
all reconnecting
back at once.  A test with iptables blocking 6633 on the controller until all 
nodes are gone
from operational then flushing the rule would simulate that.

This seems like a somewhat valid real world scenario which might make the bug 
more important
to fix.

just a thought.

JamO


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

Reply via email to