> On Oct 14, 2016, at 12:49 PM, Jamo Luhrsen <jluhr...@gmail.com> wrote:
> 
> 
> 
> On 10/14/2016 12:37 PM, Luis Gomez wrote:
>> 
>>> On Oct 14, 2016, at 9:18 AM, Jamo Luhrsen <jluhr...@gmail.com 
>>> <mailto:jluhr...@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>> 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.
>> 
>> So far it is only l2switch application (loop removal and address tracker to 
>> be more precise) that has issues with this switch
>> quick disconnect-reconnect. I am not sure what you are asking here, trying 
>> with other OF apps?
> 
> I'm asking if the problem exists (same l2switch app and ODL setup) when you 
> "isolate" the network
> from the controller and bring it back.  As opposed to the (probably assumed) 
> contrived fake automated
> "mininet" up/down test.  I'm coming from the angle of figuring out if this is 
> a regression that
> could hit end users or just a CSIT regression that maybe is less priority to 
> fix.

AFAIK mininet up/down generates very "real" OVS operations, I can try with 
iptables or OVS commands (connect/disconnect channel) but I do not think that 
will change much.

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