Operating System: Linux
Platform: PC

Attachment stdout.log has been added with description: test stdout

Attachment karaf.log has been added with description: karaf.log

From meeting minutes of the meeting June 15:

• https://bugs.opendaylight.org/show_bug.cgi?id=3735 OPNFLWPLUG-501 - flows not removed from the switch when 80k flows configured (abhijitkumbhare, 16:18:55)
  *michal_rehak says probably clean the device of flows when switch connects (but will need to be configurable - which will need API change) (abhijitkumbhare, 16:21:05)
• abhijitkumbhare & LuisGomez say this is not a blocker (abhijitkumbhare, 16:22:42)
• Clarification: abhijitkumbhare thinks this may be too late to fix (abhijitkumbhare, 16:24:38)

We will not be fixing this in Lithium release - as it was decided in the meeting this needs more thought and needs to be done in Beryllium.

the issue was initially observed when testing Lithium RC1 from June 15 for Lithium designed plugin (odl-openflowplugin-flow-services-ui-li)

The issue was also observed today while testing distribution-karaf-0.3.0-Lithium-RC1-v201506180115.tar.gz and the old-designed plugin (odl-openflowplugin-flow-services-ui). Log in attachment.

Attachment karaf.log has been added with description: He designed log

Will start looking into this.

Hi Peter,

Need more information on this bug.

1) Pasted the steps from the bug summary. Could you let me know if the script was running bulk-delete while you restarted the mininet?
2) Generally when you restart the mininet, the flows will be reprogrammed onto the switch as flows are still in configuration data-store. I wonder why other switches don’t show flows count.
3) Does it mean the bulk-delete haven’t completed (on switches under question) while you took the snapshot of get-total-found.sh output?

Michal,
I see your suggestion is to have a configurable function which will delete the flows when operational data-store don’t have flows. Hope you suggested to delete the flows from configuration data store – correct?

<Snipped from bug description>

steps:
1 connect mininet, 63 switches,
2) runs the script
test/tools/odl-mdsal-clustering-tests/clustering-performance-test/flow_stats_stability_monitor.py --host 10.25.2.9 --auth --fpr 20 --config_monitor 750 --deconfig_monitor 200 --monitor_period 30 --flows 16000 --threads 5 --bulk-delete
3) once 80k flows configured, restart mininet

this is not replicable on demand, it happened once
after flows were deconfigured, 2520 were not removed from the switch

linux-gnu>./get-total-found.sh
Switch s1: 0 flows
Switch s2: 0 flows
...
Switch s19: 0 flows
Switch s20: 0 flows
Switch s21: 0 flows
Switch s22: 1260 flows
Switch s23: 0 flows
Switch s24: 0 flows
Switch s25: 0 flows
Switch s26: 0 flows
Switch s27: 0 flows
Switch s28: 0 flows
Switch s29: 0 flows
Switch s30: 1260 flows

Thanks,
Hari

(In reply to Hariharan Sethuraman from comment #5)
> Hi Peter,
>
> Need more information on this bug.
>
> 1) Pasted the steps from the bug summary. Could you let me know if the
> script was running bulk-delete while you restarted the mininet?
> 2) Generally when you restart the mininet, the flows will be reprogrammed
> onto the switch as flows are still in configuration data-store. I wonder why
> other switches don’t show flows count.
> 3) Does it mean the bulk-delete haven’t completed (on switches under
> question) while you took the snapshot of get-total-found.sh output?
>
> Michal,
> I see your suggestion is to have a configurable function which will delete
> the flows when operational data-store don’t have flows. Hope you suggested
> to delete the flows from configuration data store – correct?
>
> <Snipped from bug description>
>
> steps:
> 1 connect mininet, 63 switches,
> 2) runs the script
> test/tools/odl-mdsal-clustering-tests/clustering-performance-test/
> flow_stats_stability_monitor.py --host 10.25.2.9 --auth --fpr 20
> --config_monitor 750 --deconfig_monitor 200 --monitor_period 30 --flows
> 16000 --threads 5 --bulk-delete
> 3) once 80k flows configured, restart mininet
>
>
> this is not replicable on demand, it happened once
> after flows were deconfigured, 2520 were not removed from the switch
>
>
> linux-gnu>./get-total-found.sh
> Switch s1: 0 flows
> Switch s2: 0 flows
> ...
> Switch s19: 0 flows
> Switch s20: 0 flows
> Switch s21: 0 flows
> Switch s22: 1260 flows
> Switch s23: 0 flows
> Switch s24: 0 flows
> Switch s25: 0 flows
> Switch s26: 0 flows
> Switch s27: 0 flows
> Switch s28: 0 flows
> Switch s29: 0 flows
> Switch s30: 1260 flows
>
> Thanks,
> Hari

I can reproduce it consistently. Please ignore my information request. Thanks.

From the reproduced setup logs - device got disconnected just before nodes deletion from config data store. So, after deletion the device however reconnects and wont have any effect and flows in device remain intact. This should be covered as part of flow reconciliation.

It is difficult to distinguish between the above explained scenario and manually flows programmed directly on the switch case.

Will be auto-addressed when flow reconciliation is implemented

Since Hari's comments indicate this will be addressed as part of reconciliation

Lowering the priority of this. Luis & I were thinking this may not even be a bug - just keeping it to be explored when get a chance in future.

Muthu,

Will this be fixed as part of reconciliation?

Abhijit