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-73 netconf <p>When user sends a DELETE request to /restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-sal-netconf-connector-cfg:sal-netconf-connector/$DEVICE_NAME (where $DEVICE_NAME is a name of a device mounted via netconf-connector), the response is sent before the device removal is fully completed. This can be observed by executing a GET request to /restconf/operational/network-topology:network-topology/topology/topology-netconf (the device $DEVICE_NAME will still be mentioned in the returned data).</p> <p>This is most likely going to be a problem as most applications using an API like this assume the device is completely released once a "disconnect" request replies with the OK response. The behavior of netconf breaks this assumption which might cause corruption of the data on the device once the DELETE requestor tries to access the device in a way that is not netconf mount compatible.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-73

Device delete request returns response before the device removal is fully completed.

Bug Resolved Cannot Reproduce Unassigned Jozef Behran Fri, 25 Sep 2015 08:39:31 +0000 Fri, 15 Mar 2019 22:22:14 +0000 Fri, 25 Sep 2015 11:25:35 +0000 netconf 0 1 <p>My point of view:<br/> Config datastore contains a desired state, motto: may not be true yet.<br/> Operational datastore contains state as detected, motto: may not be true anymore.<br/> RESTCONF guarantees that the RPC or edit of config datastore was applied.</p> <p>Presence of device in topology-netconf (as opposed to netconf-connector configutration mounted at controller-config) is an operational consequence, it reflects state detected by netconf-connector.<br/> Change of the state (in this case teardown of netconf connection to device) is triggered by change of controller-config configuration, but it happens asynchronously. 200 on your delete means netconf-connector configuration was deleted, but the triggered teardown is still pending.</p> <p>It may be useful to have a blocking request for this type of teardown, but that would be an improvement.<br/> Current behavior is consistent with both datastore semantics and RESTCONF, so I guess this Bug is Invalid.</p> <p>For tests, I recommend to WUKS to see device gone from topology-netconf.</p> <p>ODL needs a feature for the scenario described in this bug. Right now the user is forced to poll the operational state until he sees the device to go away.</p> Development External issue ID 4356 External issue URL Rank 0|i01waf: