[NETCONF-73] Device delete request returns response before the device removal is fully completed. Created: 25/Sep/15  Updated: 15/Mar/19  Resolved: 25/Sep/15

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Jozef Behran Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 4356

 Description   

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).

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.

 Comments   
Comment by Vratko Polak [ 25/Sep/15 ]

My point of view:
Config datastore contains a desired state, motto: may not be true yet.
Operational datastore contains state as detected, motto: may not be true anymore.
RESTCONF guarantees that the RPC or edit of config datastore was applied.

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.
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.

It may be useful to have a blocking request for this type of teardown, but that would be an improvement.
Current behavior is consistent with both datastore semantics and RESTCONF, so I guess this Bug is Invalid.

For tests, I recommend to WUKS to see device gone from topology-netconf.

Comment by Jozef Behran [ 25/Sep/15 ]

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.

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