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/NETCONF-459 netconf <p>Topology Owner Ha suite tries to repeatedly configure and deconfigure multiple netconf mounpoints. After that suite reboots topology owner and expects maximum number of configured netconf mountpoints. This ends in following error:<br/> <a href="https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-cluster-stress-all-nitrogen/46/log.html.gz#s1-s2-t7" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-cluster-stress-all-nitrogen/46/log.html.gz#s1-s2-t7</a></p> <p>There can be some issue with deleting ountpoints when netconf topology is under stress, but we should also check the correctness of the suite, because now I am not sure how it exactly works.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-459

Deleting mountpoints when netconf-topology is under stress seems not to work properly

Bug Confirmed Unresolved Unassigned Jakub Morvay Thu, 24 Aug 2017 17:28:29 +0000 Tue, 13 Aug 2019 07:38:40 +0000 netconf 0 1 <p>&gt; following error:</p> <p>Here <span class="error">&#91;1&#93;</span> is the raw data from topology-netconf. You can see that there is one device with lower port number, stuck in "connecting" status:</p> <p>{"node-id":"netconf-test-device-17831-5","netconf-node-topology:available-capabilities":{},"netconf-node-topology:host":"10.29.13.99","netconf-node-topology:unavailable-capabilities":{},"netconf-node-topology:connection-status":"connecting","netconf-node-topology:port":17831}</p> <p>Configurer output <span class="error">&#91;2&#93;</span>:<br/> (delete:200)x102, (put:201)x123<br/> means the expected number of devices to be seen is 21, presumably implying netconf-test-device-17831-5 has been deleted from config datastore, but not from topology.</p> <p>There is also log from testtool <span class="error">&#91;3&#93;</span>, but it is debug level, so not easy to read.</p> <p>&gt; we should also check the correctness of the suite, because now I am not sure how it exactly works.</p> <p>Most of the work is done by the configurer script <span class="error">&#91;4&#93;</span>. Previously the suite was quite broken, but I think it works correctly now.</p> <p><span class="error">&#91;1&#93;</span> <a href="https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-cluster-stress-all-nitrogen/46/log.html.gz#s1-s2-t7-k2-k1-k1-k1-k4-k1" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-cluster-stress-all-nitrogen/46/log.html.gz#s1-s2-t7-k2-k1-k1-k1-k4-k1</a><br/> <span class="error">&#91;2&#93;</span> <a href="https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-cluster-stress-all-nitrogen/46/configurer--netconf-cluster-stress-txt-Topology-Owner-Ha.log.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-cluster-stress-all-nitrogen/46/configurer--netconf-cluster-stress-txt-Topology-Owner-Ha.log.gz</a><br/> <span class="error">&#91;3&#93;</span> <a href="https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-cluster-stress-all-nitrogen/46/testtool--netconf-cluster-stress-txt-Topology-Owner-Ha.log.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-cluster-stress-all-nitrogen/46/testtool--netconf-cluster-stress-txt-Topology-Owner-Ha.log.gz</a><br/> <span class="error">&#91;4&#93;</span> <a href="https://github.com/opendaylight/integration-test/blob/master/tools/netconf_tools/configurer.py" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/opendaylight/integration-test/blob/master/tools/netconf_tools/configurer.py</a></p> Development External issue ID 9049 External issue URL Rank 0|i01yo7: