[DOCS-150] problems with GET/POST/DELETE of list elements with key of type instance-identifier

Mon, 18 Dec 2023 12:13:25 +0000

version: karaf 18.3 and 19.1

I have the following GET working fine.

Please note that "interface" is a list with key "name".
Please note that "name" is an instance-identifier pointing to an instance of /smo-interfaces:interfaces/if[typeIf='lan'][idx='1']
Please note that "if" is list with keys typeIf,idx

curl -X GET -u admin:admin -H "content-type: application/yang-data+json" http://172.17.0.72:8181/rests/data/network-topology:network-topology/topology=topology-netconf/node=new-netconf-device-serverssh_telstar_6126_brigam_1/yang-ext:mount/smo-routing:routing/control-plane-protocol=MANAGEMENT-PLANE/smo-is-is:isis?fields=interface
{"smo-is-is:isis":{"interface":[

{"name":"/smo-interfaces:interfaces/if[typeIf='lan'][idx='1']","priority1":16}

]}}

--> OK

------------------------------------------

I'm not able to GET directly the "interface" list element whose key is name
using the restconf format for the "name" instance-identifier

{ "error-tag": "invalid-value", "error-info": "Failed to lookup prefix ", "error-message": "Invalid value '/smo-interfaces:interfaces/if[typeIf='lan'][idx='1']' for (http://www.sm-optics.com/yang/isis?revision=2020-09-18)name", "error-type": "protocol" }

]
}
}

--> KO

The only way to do it is to use the netconf-like instance-identifier format for the "name" key.

However this is not the format indicated in https://datatracker.ietf.org/doc/html/rfc7951#section-6.11

--> OK

--------------

I'm not able to DELETE directly the "interface" list element whose key is name
using the restconf format for the "name" instance-identifier

curl -X DELETE -u admin:admin -H "content-type: application/yang-data+json" http://172.17.0.72:8181/rests/data/network-topology:network-topology/topology=topology-netconf/node=new-netconf-device-serverssh_telstar_6126_brigam_1/yang-ext:mount/smo-routing:routing/control-plane-protocol=MANAGEMENT-PLANE/smo-is-is:isis/interface=%2Fsmo-interfaces%3Ainterfaces%2Fsmo-interfaces%3Aif%5BtypeIf%3D%27lan%27%5D%5Bsmo-interfaces%3Aidx%3D%271%27%5D
{
"errors": {
"error": [

{ "error-tag": "invalid-value", "error-info": "Failed to lookup prefix ", "error-message": "Invalid value '/smo-interfaces:interfaces/smo-interfaces:if[typeIf='lan'][smo-interfaces:idx='1']' for (http://www.sm-optics.com/yang/isis?revision=2020-09-18)name", "error-type": "protocol" }

]
}
}

--> KO

The only way to do it is to use the netconf-like instance-identifier format for the "name" key.

However this is not the format indicated in https://datatracker.ietf.org/doc/html/rfc7951#section-6.11

curl -X DELETE -u admin:admin -H "content-type: application/yang-data+json" http://172.17.0.72:8181/rests/data/network-topology:network-topology/topology=topology-netconf/node=new-netconf-device-serverssh_telstar_6126_brigam_1/yang-ext:mount/smo-routing:routing/control-plane-protocol=MANAGEMENT-PLANE/smo-is-is:isis/interface=%2Fsmo-interfaces%3Ainterfaces%2Fsmo-interfaces%3Aif%5Bsmo-interfaces%3AtypeIf%3D%27lan%27%5D%5Bsmo-interfaces%3Aidx%3D%271%27%5D

--> OK

--------------

Creation of the "interface" list element is failing with error 500 in html format (it should be restconf json format),

however it is created successfully in the ssh server

curl -X POST -u admin:admin -H "content-type: application/yang-data+json" http://172.17.0.72:8181/rests/data/network-topology:network-topology/topology=topology-netconf/node=new-netconf-device-serverssh_telstar_6126_brigam_1/yang-ext:mount/smo-routing:routing/control-plane-protocol=MANAGEMENT-PLANE/smo-is-is:isis --data '{"smo-is-is:interface": [

{"name": "/smo-interfaces:interfaces/if[typeIf='\''lan'\''][idx='\''1'\'']", "priority1": 16}

]}'

<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 500 Request failed.</title>
</head>
<body><h2>HTTP ERROR 500 Request failed.</h2>
<table>
<tr><th>URI:</th><td>/rests/data/network-topology:network-topology/topology=topology-netconf/node=new-netconf-device-serverssh_telstar_6126_brigam_1/yang-ext:mount/smo-routing:routing/control-plane-protocol=MANAGEMENT-PLANE/smo-is-is:isis</td></tr>
<tr><th>STATUS:</th><td>500</td></tr>
<tr><th>MESSAGE:</th><td>Request failed.</td></tr>
<tr><th>SERVLET:</th><td>org.glassfish.jersey.servlet.ServletContainer</td></tr>
</table>

</body>
</html>

--> KO

The same error in case the netconf-like instance-identifier format is used:

{"name": "/smo-interfaces:interfaces/smo-interfaces:if[smo-interfaces:typeIf='\''lan'\''][smo-interfaces:idx='\''1'\'']", "priority1": 16}

]}'
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 500 Request failed.</title>
</head>
<body><h2>HTTP ERROR 500 Request failed.</h2>
<table>
<tr><th>URI:</th><td>/rests/data/network-topology:network-topology/topology=topology-netconf/node=new-netconf-device-serverssh_telstar_6126_brigam_1/yang-ext:mount/smo-routing:routing/control-plane-protocol=MANAGEMENT-PLANE/smo-is-is:isis</td></tr>
<tr><th>STATUS:</th><td>500</td></tr>
<tr><th>MESSAGE:</th><td>Request failed.</td></tr>
<tr><th>SERVLET:</th><td>org.glassfish.jersey.servlet.ServletContainer</td></tr>
</table>

</body>
</html>

ODL LOG during POST is attached as a file

From our SSH log we see that the command is successfully executed:

Session 18 [DBG]: 2023-12-18T11:02:38Z: Received message:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-172" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-172"><ok/></rpc-reply>

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-173" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<routing xmlns="http://www.sm-optics.com/yang/routing" xmlns:op="urn:ietf:params:xml:ns:netconf:base:1.0" op:operation="merge">
<control-plane-protocol>
<name>MANAGEMENT-PLANE</name>
<isis xmlns="http://www.sm-optics.com/yang/isis"/>
</control-plane-protocol>
</routing>
</config>~Untitled_6
</edit-config>
</rpc>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-173"><ok/></rpc-reply>

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-174" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<routing xmlns="http://www.sm-optics.com/yang/routing">
<control-plane-protocol>
<name>MANAGEMENT-PLANE</name>
<isis xmlns="http://www.sm-optics.com/yang/isis">
<interface xmlns:op="urn:ietf:params:xml:ns:netconf:base:1.0" op:operation="create">
<name xmlns:a="http://www.sm-optics.com/yang/if">/a:interfaces/a:if[a:typeIf='lan'][a:idx='1']</name>
<priority1>16</priority1>
</interface>
</isis>
</control-plane-protocol>
</routing>
</config>
</edit-config>
</rpc>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-174"><ok/></rpc-reply>

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-175" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-175"><ok/></rpc-reply>

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-176" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-176"><ok/></rpc-reply>

Doing a GET we see that it is present:

curl -X GET -u admin:admin -H "content-type: application/yang-data+json" http://172.17.0.72:8181/rests/data/network-topology:network-topology/topology=topology-netconf/node=new-netconf-device-serverssh_telstar_6126_brigam_1/yang-ext:mount/smo-routing:routing/control-plane-protocol=MANAGEMENT-PLANE/smo-is-is:isis?fields=interface
{"smo-is-is:isis":{"interface":[

{"name":"/smo-interfaces:interfaces/if[typeIf='lan'][idx='1']","priority1":16}

]}}

--> OK, it was created even if an error was returned to the POST

OpenDaylight JIRA

[DOCS-150] problems with GET/POST/DELETE of list elements with key of type instance-identifier