Thanks Sai, yes I have a question regrading the first issue below: any idea why 
address tracker would keep discovered IP address information after restarting 
mininet? like what is today in the code to flush the address cache and why this 
is not working when mininet restarts?

BR/Luis

> On Oct 18, 2016, at 6:56 PM, Sai MarapaReddy <sai.marapare...@gmail.com> 
> wrote:
> 
> Thanks Luis. 
> 
> Yes that is drop-all flow. Please let us know if you need any further help 
> from l2switch. 
> 
> On Tue, Oct 18, 2016 at 1:03 PM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> Actually this is the drop flow so it is expected, anyway going deeper into 
> l2switch test issues I see:
> 
> - The address tracker issue is because hosts addresses are not getting 
> cleared when we restart mininet with no sleep in-between.
> - The loop remover issue could be related to some test issue, I am trying to 
> clean up/repair the test here: https://git.opendaylight.org/gerrit/#/c/47095/ 
> <https://git.opendaylight.org/gerrit/#/c/47095/>
> 
> BR/Luis
> 
> > On Oct 18, 2016, at 10:02 AM, Luis Gomez <ece...@gmail.com 
> > <mailto:ece...@gmail.com>> wrote:
> >
> > There are definitely weird things going on in l2switch, the first ERROR you 
> > mention produces some weird flow (no match and no action) in the switch:
> >
> >             Flow 55:
> >                "cookie": 3098476543630901303,
> >                "flags": "",
> >                "hard-timeout": 0,
> >                "id": "55",
> >                "idle-timeout": 0,
> >                "match": {},
> >                "opendaylight-flow-statistics:flow-statistics": {
> >                    "byte-count": 0,
> >                    "duration": {
> >                        "nanosecond": 239000000,
> >                        "second": 36
> >                    },
> >                    "packet-count": 0
> >                },
> >                "priority": 0,
> >                "table_id": 0
> >
> >
> > The second issue, I am not sure what is the impact but definitely something 
> > to look at.
> >
> > I think in general we will need l2switch support to troubleshoot and 
> > progress in current issues.
> >
> > BR/Luis
> >
> >
> >> On Oct 17, 2016, at 8:09 AM, Miroslav Macko <miroslav.ma...@pantheon.tech> 
> >> wrote:
> >>
> >> Hello Luis and dev guys,
> >>
> >> There is this info from l2-switch in the karaf log:
> >>
> >> 2016-10-14 22:43:24,941 | INFO  | pool-16-thread-1 | FlowWriterServiceImpl 
> >>            | 229 - org.opendaylight.l2switch.main.impl - 0.5.0.SNAPSHOT | 
> >> In addMacToMacFlowsUsingShortestPath: No flows added. Source and 
> >> Destination ports are same.
> >>
> >> Is it ok?
> >>
> >> And this debug message(it has incorrect severity):
> >>
> >> 2016-10-14 22:43:55,282 | ERROR | entLoopGroup-5-3 | 
> >> DeviceFlowRegistryImpl           | 210 - 
> >> org.opendaylight.openflowplugin.impl - 0.4.0.SNAPSHOT | Flow with flowId 
> >> 85 already exists in table 0
> >>
> >> So it looks like that flows with the same ID are added.
> >>
> >> What in short these failing tests are doing and what it should test please?
> >>
> >> Thanks,
> >> Miro
> >>
> >> ________________________________________
> >> Od: Luis Gomez <ece...@gmail.com <mailto:ece...@gmail.com>>
> >> Odoslané: 15. októbra 2016 1:01
> >> Komu: Tomáš Slušný
> >> Kópia: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev
> >> Predmet: Re: [openflowplugin-dev] [L2switch-dev] Blocker bug analysis
> >>
> >> No luck :), still fails on "address tracker" and "loop remover":
> >>
> >> https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/154/
> >>  
> >> <https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-carbon/154/>
> >> https://logs.opendaylight.org/releng/jenkins092/l2switch-csit-1node-switch-only-carbon/154/archives/log.html.gz
> >>  
> >> <https://logs.opendaylight.org/releng/jenkins092/l2switch-csit-1node-switch-only-carbon/154/archives/log.html.gz>
> >>
> >> BR/Luis
> >>
> >>
> >>> On Oct 14, 2016, at 2:26 PM, Luis Gomez <ece...@gmail.com 
> >>> <mailto:ece...@gmail.com>> wrote:
> >>>
> >>> OK Tomas, I will try your patch 
> >>> https://git.opendaylight.org/gerrit/#/c/46390/ 
> >>> <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/ 
> >>>> <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/
> >>>>  
> >>>> <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/ 
> >>>> <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 <mailto: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 
> >>>>> <mailto: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 
> >>>>>> <mailto:abhijitk...@gmail.com>> wrote:
> >>>>>>
> >>>>>> About the first one - 
> >>>>>> https://bugs.opendaylight.org/show_bug.cgi?id=6575 
> >>>>>> <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 
> >>>>>> <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 
> >>>>>> <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 
> >>>>>> <mailto: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 
> >>>>>> <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/
> >>>>>>  
> >>>>>> <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/
> >>>>>>  
> >>>>>> <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 
> >>>>>> <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
> >>>>>>  
> >>>>>> <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
> >>>>>>  
> >>>>>> <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 
> >>>>>> <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 <tel:%2B421%202%20206%2065%20114> / 
> >>>> www.pantheon.sk <http://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 <tel:%2B421%202%20206%2065%20114> / 
> >>>> www.pantheon.sk <http://www.pantheon.sk/>
> >>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> openflowplugin-dev mailing list
> >> openflowplugin-...@lists.opendaylight.org 
> >> <mailto:openflowplugin-...@lists.opendaylight.org>
> >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> >> <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev>
> >> MiroslavMacko
> >> Software Developer
> >>
> >> Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
> >> R&D centrum / Janka Kráľa 9 /  974 01 Banská Bystrica / Slovakia
> >> / miroslav.ma...@pantheon.tech
> >> reception: +421 2 206 65 114 <tel:%2B421%202%20206%2065%20114> / 
> >> www.pantheon.sk <http://www.pantheon.sk/>
> >>
> >> [logo]
> >>
> >>
> >
> 
> _______________________________________________
> L2switch-dev mailing list
> L2switch-dev@lists.opendaylight.org 
> <mailto:L2switch-dev@lists.opendaylight.org>
> https://lists.opendaylight.org/mailman/listinfo/l2switch-dev 
> <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