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-1097 netconf <p><a href="https://jira.opendaylight.org/browse/NETCONF-1070" title="Rework client reconnection logic" class="issue-link" data-issue-key="NETCONF-1070"><del>NETCONF-1070</del></a> which implements a new NETCONF device connection mechanism introduced changes in how <tt>connection-status</tt> is updated during reconnection attempts.</p> <p>Previously, <tt>connection-status</tt> stayed in the <tt>connecting</tt> state while reconnection is tried and transitioned to either <tt>connected</tt> (successful connection) or <tt>unable-to-connect</tt> (eventual connection failure).</p> <p>But with netconf-6.0.0, when the connection attempt fails <tt>connection-status</tt> changes to <tt>unable-to-connect</tt> and stays in the state until connection is successful and the status changes to <tt>connected</tt>.</p> <p>This makes it impossible to distinguish the following two cases with <tt>connection-status</tt>:</p> <ul> <li>Reconnection is still being tried</li> <li>Reconnection attempts were exhausted and device cannot be connected</li> </ul> <p>And since the state transitions from <tt>unable-to-connect</tt> to <tt>connected</tt> when the initial connection attempt fails, this may also affect downstream application which expects <tt>connection-status</tt> changes from <tt>connecting</tt> to <tt>connected</tt> - e.g. <a href="https://github.com/opendaylight/transportpce/blob/master/networkmodel/src/main/java/org/opendaylight/transportpce/networkmodel/NetConfTopologyListener.java#L90" class="external-link" target="_blank" rel="nofollow noopener">TransportPCE NetConfTopologyListener</a>.</p> NETCONF-1097

NETCONF connection status behavior change

Bug Medium Resolved Done Robert Varga Sangwook Ha pt regression Thu, 20 Jul 2023 23:17:43 +0000 Mon, 7 Aug 2023 09:23:24 +0000 Mon, 7 Aug 2023 09:23:24 +0000 6.0.0 7.0.0 7.0.0 6.0.1 netconf-topology 0 5 <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=gthouenon" class="user-hover" rel="gthouenon">gthouenon</a> <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=orenais" class="user-hover" rel="orenais">orenais</a> FYI</p> <p>We have to ensure that:</p> <ol> <li>when we are below max_attempts the device status is <b>connecting</b></li> <li>when we are exceeding max_attempts the device status is <b>unable-to-connect</b></li> <li>when device is turned off and on again we need to ensure transition from <b>connecting</b> to <b>connected</b></li> <li>when device is turned off and on again we need to ensure that device stays in <b>unable-to-connect</b></li> </ol> <p><b>All these requirements are satisfied in 5.0.x branch.</b></p> <p>The option #3 can be tested when running testool (which automatically creates <b>17830-sim-device</b>) and simultaneously creating another topology node, for example <b>test-device</b> with the same configuration as <b>17830-sim-device</b>.</p> <p>Now, after turning off and on testtool we are getting incorrect response:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>GET http://192.168.56.25:8181/rests/data/network-topology:network-topology/topology=topology-netconf?fields=node/node-id;node/netconf-node-topology:connection-status</pre> </div></div> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>{     "network-topology:topology": [         {             "node": [                 {                     "node-id": "17830-sim-device",                     "netconf-node-topology:connection-status": "connected"                 },                 {                     "node-id": "test-device",                     "netconf-node-topology:connection-status": "unable-to-connect"                 }             ]         }     ] }</pre> </div></div> <p>We expect both devices to be <b>connected</b>. Assuming the devices max_attempt to reconnect are not exceeded.</p> <p>...</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>"netconf-node-topology:max-connection-attempts": 0</pre> </div></div> <p>...</p> <p>is used to set unlimited connection attempts.</p> <p>Ready for review, to p[prevent further occurrences of similar issues we will create unit tests in <a href="https://jira.opendaylight.org/browse/NETCONF-1119" title="Create unit tests for NETCONF connection status behavior change" class="issue-link" data-issue-key="NETCONF-1119"><del>NETCONF-1119</del></a>.</p> <p>This issue shows that we are quite lacking in terms of API definition. The callbacks in RemoteDeviceHandler have no attached meaning, but implementation experience shows there is an implicit lifecycle contract expressed therein.</p> Issue split NETCONF-1119 NETCONF-1121 Relates NETCONF-1070 Development Rank 0|i045un: