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> 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/
>
> BR/Luis
>
> > On Oct 18, 2016, at 10:02 AM, Luis Gomez <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>
> >> 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://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> wrote:
> >>>
> >>> 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-dev@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-...@lists.opendaylight.org
> >> 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 / www.pantheon.sk
> >>
> >> [logo]
> >>
> >>
> >
>
> _______________________________________________
> L2switch-dev mailing list
> 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