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

Reply via email to