https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OVSDB-382 ovsdb <p>this is causing some failure(s) in CSIT, so starting with elevated severity as we want to keep CSIT passing 100%</p> <p>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<br/> is created via config store request.</p> <p>steps:</p> <ul class="alternate" type="square"> <li>set ovs to passive</li> <li>connect to ovs via ODL NB rest api</li> <li>create a new "node" via NB api</li> <li>create a qos entry</li> <li>create a queue entry</li> <li>link the qos and queue to the "node"</li> <li>delete the queue entry</li> <li>delete the qos entry</li> <li>delete the node</li> <li>disconnect ovs</li> <li>delete the original connection info</li> </ul> <p>at this point the operational will still contain the two nodes.</p> <p>The CSIT job that can be used to replicate this is here:<br/> <a href="https://logs.opendaylight.org/releng/jenkins092/ovsdb-csit-1node-southbound-only-carbon/203/archives/log.html.gz#s1-s4" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/ovsdb-csit-1node-southbound-only-carbon/203/archives/log.html.gz#s1-s4</a></p> <p>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.</p> <p>Operating System: All<br/> Platform: All</p> OVSDB-382

operational store still has node after ovs disconnects

Bug Resolved Done Anil Vishnoi Jamo Luhrsen Sat, 12 Nov 2016 00:27:56 +0000 Mon, 13 Mar 2017 19:54:22 +0000 Mon, 13 Mar 2017 19:54:22 +0000 unspecified Southbound.Open_vSwitch 0 2 <p>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.</p> <p>Attachment karaf.log.gz has been added with description: karaf log from CSIT job</p> <p>Hi Jamo,</p> <p>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.</p> <p>we have CSIT for it:</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/ovsdb-csit-1node-southbound-only-carbon/393/archives/log.html.gz#s1-s6" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/ovsdb-csit-1node-southbound-only-carbon/393/archives/log.html.gz#s1-s6</a></p> <p>Okay so this is the bug where we delete the "ConnectionInfo" but not the entire node?</p> <p>(In reply to Anil Vishnoi from comment #4)<br/> &gt; Okay so this is the bug where we delete the "ConnectionInfo" but not the<br/> &gt; entire node?</p> <p>yeah, something like that. the robot test case (and the steps in comment 1) are<br/> probably the best way to remember it. But, we also have this kind of summary<br/> email:</p> <p><a href="https://lists.opendaylight.org/pipermail/ovsdb-dev/2016-December/004015.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/ovsdb-dev/2016-December/004015.html</a></p> <p>stable/boron : <a href="https://git.opendaylight.org/gerrit/52985" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/52985</a></p> <p>master : <a href="https://git.opendaylight.org/gerrit/#/c/53168/2" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/53168/2</a></p> Development External issue ID 7160 External issue URL Rank 0|i022dz: