Thanks Luis and Abhijit, Based on your comments below, I have retargeted the blocker bug for Boron-SR2.
Best Regards, An Ho From: Abhijit Kumbhare [mailto:abhijitk...@gmail.com] Sent: Tuesday, October 25, 2016 1:42 PM To: Luis Gomez Cc: An Ho; openflowplugin-dev; OpenDayLight-L2switch-Dev Subject: Re: [L2switch-dev] [openflowplugin-dev] l2switch blocker bug Yes - I agree. On Tue, Oct 25, 2016 at 1:07 PM, Luis Gomez <ece...@gmail.com<mailto:ece...@gmail.com>> wrote: I do not think there is fix for l2switch issue yet, [2] is just a logging change. I would suggest to defer this for Boron-SR2 if nobody objects. On Oct 25, 2016, at 10:54 AM, An Ho <an...@huawei.com<mailto:an...@huawei.com>> wrote: Hi Sai and L2Switch Team, We would like to check in on the status of bug 6575 [1]. Sai submitted patch 47186 [2]. Is this bug still a blocker or should we downgrade it to critical instead? What is the ETA for merging the fix or should we retarget the bug for Boron-SR2/Carbon instead? Our goal is to respin by 4PM Pacific Time Zone; please let us know if further delay is necessary. Best Regards, An Ho [1] https://bugs.opendaylight.org/show_bug.cgi?id=6575 [2] https://git.opendaylight.org/gerrit/#/c/47186/ From: Luis Gomez [mailto:ece...@gmail.com] Sent: Monday, October 24, 2016 5:14 PM To: Sai MarapaReddy Cc: Jamo Luhrsen; An Ho; Tomáš Slušný; openflowplugin-dev; OpenDayLight-L2switch-Dev; Miroslav Macko Subject: Re: [L2switch-dev] [openflowplugin-dev] l2switch blocker bug Hi Sai, Here is the build with your patch and sleep 2: https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-only-boron/819/ BR/Luis On Oct 21, 2016, at 4:02 AM, Sai MarapaReddy <sai.marapare...@gmail.com<mailto:sai.marapare...@gmail.com>> wrote: Luis, https://logs.opendaylight.org/releng/jenkins092/l2switch-csit-1node-switch-only-boron/798/archives/karaf.log.gz At around time stamp 2016-10-21 08:51:21,269 in the above build, shows some addresses in MD-SAL data tree which are identical to the addresses that are going to be created (when a mininet is re-connected). Please run the patch [1] against csit jobs which has a sleep of 2 seconds in between mininet connection / disconnection. If we don't see any existing addresses in data tree, we can confirm the cause of the issue. [1] https://git.opendaylight.org/gerrit/#/c/47186/ On Thu, Oct 20, 2016 at 5:02 PM, Luis Gomez <ece...@gmail.com<mailto:ece...@gmail.com>> wrote: (Resending with less content and changing title) Here is the run with your patch: https://jenkins.opendaylight.org/releng/job/l2switch-csit-1node-switch-only-boron/795/ Please let us know if we can help with anything. BR/Luis On Oct 20, 2016, at 10:54 AM, Sai MarapaReddy <sai.marapare...@gmail.com<mailto:sai.marapare...@gmail.com>> wrote: Done. Thanks Jamo. On Thu, Oct 20, 2016 at 10:39 AM, Jamo Luhrsen <jluhr...@gmail.com<mailto:jluhr...@gmail.com>> wrote: On 10/19/2016 11:26 PM, Sai MarapaReddy wrote: > Address tracker tries [1] to read any existing address from data store. My > guess is in the case of immediate restart of > mininet , addresses from data store are not cleaned and this is why we see > all addresses. > > In further attempt to verify this information I have a patch here [2]. I > tried running it with keyword "test-l2switch-all" > but no success. Could you please run it. This might help in troubleshooting > the issue further. it's because we don't have a patch test job for l2switch yet. It's something projects are adding on an as-needed basis. I gave you one here: https://git.opendaylight.org/gerrit/#/c/47219/ give it a +1 and we can try to get it merged. Thanks, JamO > [1] > https://github.com/opendaylight/l2switch/blob/stable/boron/addresstracker/implementation/src/main/java/org/opendaylight/l2switch/addresstracker/addressobserver/AddressObservationWriter.java#L116 > > [2] https://git.opendaylight.org/gerrit/#/c/47186/ > > On Wed, Oct 19, 2016 at 9:43 AM, Luis Gomez > <ece...@gmail.com<mailto:ece...@gmail.com> > <mailto:ece...@gmail.com<mailto:ece...@gmail.com>>> wrote: > > Hi Sai, after looking at the test more in detail this is not exactly the > behavior (sorry for the confusion), what is > really happening is: > > - Mininet restarts > - There is no host in address-tracker after restart > - We do the classic mininet pingall test > - After the pingall test the host addresses (10.0.0.1, 10.0.0.2, > 10.0.0.3) are seen in all switches, while in normal > scenario 10.0.0.1 should be only in s1 to-host port, 10.0.0.2 should be > only in s2 to-host port and 10.0.0.3 should be > only in s3 to-host port. > > The normal scenario happens when we leave 2 secs between mininet stop + > start. > > So 2 questions: > > - What is the impact of address tracker registering remote IP addresses > in the switch-to-switch ports? As far as I can > see flows are generated correctly even in this case. > - Any idea why the address tracker would get confused and add IP > addresses to the switch-to-switch ports? maybe the > application fails to identify these ports as going switch-to-switch? > > BR/Luis > _______________________________________________ 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
