[OVSDB-382] operational store still has node after ovs disconnects Created: 12/Nov/16  Updated: 13/Mar/17  Resolved: 13/Mar/17

Status: Resolved
Project: ovsdb
Component/s: Southbound.Open_vSwitch
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Jamo Luhrsen Assignee: Anil Vishnoi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File karaf.log.gz    
External issue ID: 7160

 Description   

this is causing some failure(s) in CSIT, so starting with elevated severity as we want to keep CSIT passing 100%

in summary, there is a specific set of steps where the operational store will still contain node data even after the ovs has been disconnected (ovs-vsctl del-manager). In this test, ovs is set to passive mode and the connection
is created via config store request.

steps:

  • set ovs to passive
  • connect to ovs via ODL NB rest api
  • create a new "node" via NB api
  • create a qos entry
  • create a queue entry
  • link the qos and queue to the "node"
  • delete the queue entry
  • delete the qos entry
  • delete the node
  • disconnect ovs
  • delete the original connection info

at this point the operational will still contain the two nodes.

The CSIT job that can be used to replicate this is here:
https://logs.opendaylight.org/releng/jenkins092/ovsdb-csit-1node-southbound-only-carbon/203/archives/log.html.gz#s1-s4

note the failures in CSIT are happening later, but I am assuming this problem is what is causing the failures in the tests after it.



 Comments   
Comment by Jamo Luhrsen [ 12/Nov/16 ]

my guess is that something is breaking when the ovs disconnects (via del-manager) an the node is still in both operational and config. To find that point in the test in the karaf.log you can search for this timestamp "2016-11-11 16:23:18,576" otherwise, the robot tests are marking the karaf.log with a message at the start of each test case. search for "ROBOT MESSAGE" in the karaf.log for those instances.

Comment by Jamo Luhrsen [ 12/Nov/16 ]

Attachment karaf.log.gz has been added with description: karaf log from CSIT job

Comment by Anil Vishnoi [ 02/Feb/17 ]

Hi Jamo,

Current CI looks good, so i assume this bug is resolved now ? I am closing this bug, but if you think it still existing, please re-open the bug.

Comment by Jamo Luhrsen [ 02/Feb/17 ]

we have CSIT for it:

https://logs.opendaylight.org/releng/jenkins092/ovsdb-csit-1node-southbound-only-carbon/393/archives/log.html.gz#s1-s6

Comment by Anil Vishnoi [ 02/Feb/17 ]

Okay so this is the bug where we delete the "ConnectionInfo" but not the entire node?

Comment by Jamo Luhrsen [ 03/Feb/17 ]

(In reply to Anil Vishnoi from comment #4)
> Okay so this is the bug where we delete the "ConnectionInfo" but not the
> entire node?

yeah, something like that. the robot test case (and the steps in comment 1) are
probably the best way to remember it. But, we also have this kind of summary
email:

https://lists.opendaylight.org/pipermail/ovsdb-dev/2016-December/004015.html

Comment by Anil Vishnoi [ 08/Mar/17 ]

stable/boron : https://git.opendaylight.org/gerrit/52985

Comment by Anil Vishnoi [ 11/Mar/17 ]

master : https://git.opendaylight.org/gerrit/#/c/53168/2

Generated at Wed Feb 07 20:36:15 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.