-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
None
-
version: karaf 18.3 and 19.1
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 as indicated in https://datatracker.ietf.org/doc/html/rfc7951#section-6.11
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/interface=%2Fsmo-interfaces%3Ainterfaces%2Fif%5BtypeIf%3D%27lan%27%5D%5Bidx%3D%271%27%5D
{
"errors": {
"error": [
]
}
}
--> KO
The only way ODL accepts is to use the netconf-like instance-identifier format for the "name" key, repeating all prefixes even when they do not change.
However this is not the format indicated in https://datatracker.ietf.org/doc/html/rfc7951#section-6.11
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/interface=%2Fsmo-interfaces%3Ainterfaces%2Fsmo-interfaces%3Aif%5Bsmo-interfaces%3AtypeIf%3D%27lan%27%5D%5Bsmo-interfaces%3Aidx%3D%271%27%5D
--> Accepted by ODL
--------------
I'm not able to DELETE directly the "interface" list element whose key is name
using the restconf format for the "name" instance-identifier as 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%2Fif%5BtypeIf%3D%27lan%27%5D%5Bidx%3D%271%27%5D
{
"errors": {
"error": [
]
}
}
--> KO
The only way ODL accepts it is to use the netconf-like instance-identifier format for the "name" key, repeating all prefixes even when they do not change.
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
--> Accepted by ODL
--------------
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, repeating all prefixes even when they do not change:
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/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 internal LOG during POST is attached as a file to this ticket, an internal error is traced.
From our SSH log we see that the command was successfully received and executed by SSH server and ok was sent to ODL as reply:
<?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> </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 really present after the POST:
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":[
]}}
--> OK, it was created even if an error was returned to the POST
- is blocked by
-
-
- Resolved
-
- is duplicated by
-
-
- Closed
-
- split to
-
-
- Resolved
-
1.
|
Failed to lookup prefix |
|
Confirmed | Ivan Hrasko |
