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.

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