[CONTROLLER-898] Switches not removed from Operational after clearing mininet topo Created: 25/Sep/14  Updated: 19/Oct/17  Resolved: 05/May/15

Status: Resolved
Project: controller
Component/s: adsal
Affects Version/s: Helium
Fix Version/s: None

Type: Bug
Reporter: Luis Gomez Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Duplicate
is duplicated by OPNFLWPLUG-299 notification NodeRemoved is bypassing... Resolved
External issue ID: 2089

 Description   

Steps to reproduce:

  • Download integration karaf and install odl-integration-compatible-with-all feature
  • Start mininet tree,6 topology
  • Stop mininet

Check Operational:

GET restconf/operational/opendaylight-inventory:nodes

See if there is any dummy "switch"

BR/Luis

 Comments   
Comment by Colin Dixon [ 25/Sep/14 ]

Setting severity to critical.

Comment by Tony Tkacik [ 26/Sep/14 ]

This requires additional analysis, please provide data which were present for dummy switch, since there were similar bugs for stats manager and inventory which were fixed,
but quick search on l2switch showed that they are writing data to
operational store with createParents=true,
which could introduce dummy node after inventory manager deleted it.

Without leaving dangling data is hard to reason who is offender be it stats manager,
inventory manager or l2switch project.

Moved to other, since this is not MD-SAL bug, but probably bug in one of mentioned applications.

Comment by Luis Gomez [ 26/Sep/14 ]

Hi Tony,

This issue was addressed in this patch:

https://git.opendaylight.org/gerrit/#/c/11591/

So we can clos this one. Bad news is the above patch introduced other issue discovering switches that I plan to report in a different bug.

BR/Luis

Comment by Carol Sanders [ 05/May/15 ]

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL.

Generated at Wed Feb 07 19:54:09 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.