OK Tomas, I will try your patch https://git.opendaylight.org/gerrit/#/c/46390/ 
on l2switch-csit-1node-switch-only-carbon and let you know.


> On Oct 14, 2016, at 1:23 PM, Tomáš Slušný <tomas.slu...@pantheon.tech> wrote:
> 
> Also, 6710 was already merged only in master branch, but not yet in boron. It 
> have cherry-pick ready here: https://git.opendaylight.org/gerrit/#/c/46761/, 
> but until it is merged, I think it would be better to check for improvement 
> in Jenkins test for Carbon here: 
> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/
> Od: Tomáš Slušný <tomas.slu...@pantheon.tech>
> Odoslané: 14. októbra 2016 22:13
> Komu: Luis Gomez; Abhijit Kumbhare
> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis
>  
> ​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> 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> 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> 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
>>> 
>> 
> 
> 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
> 
>  
> 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
> 
>  

_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to