The status code of a PATCH request is always 200 as long as the request passes schema validation even if a transaction of an edit fails.
For example, the following PATCH request update/create NETCONF node:
PATCH /rests/data/network-topology:network-topology/topology=topology-netconf
Accept: application/yang-data+json
Content-Type: application/yang-patch+json
{
"ietf-yang-patch:yang-patch": {
"edit": [
{
"edit-id": "edit1",
"operation": "merge",
"target": "/node=netconf-mdsal",
"value": {
"network-topology:node": [
{
"node-id": "netconf-mdsal",
"netconf-node-topology:concurrent-rpc-limit": 0,
"netconf-node-topology:schema-cache-directory": "netconf-mdsal",
"netconf-node-topology:password": "admin",
"netconf-node-topology:username": "admin",
"netconf-node-topology:default-request-timeout-millis": 1800000,
"netconf-node-topology:port": 2830,
"netconf-node-topology:tcp-only": false,
"netconf-node-topology:host": "127.0.0.1",
"netconf-node-topology:keepalive-delay": 100
}
]
}
},
{
"edit-id": "edit2",
"operation": "create",
"target": "/node=netconf-mdsal",
"value": {
"network-topology:node": [
{
"node-id": "netconf-mdsal",
"netconf-node-topology:keepalive-delay": 200
}
]
}
}
],
"patch-id": "patch1"
}
}
returns 200 along with the following yang-patch-status:
{
"ietf-yang-patch:yang-patch-status": {
"patch-id": "patch1",
"edit-status": {
"edit": [
{
"edit-id": "edit1",
"ok": [
null
]
},
{
"edit-id": "edit2",
"errors": {
"error": [
{
"error-type": "protocol",
"error-tag": "data-exists",
"error-path": "/(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology/topology/topology[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)topology-id=topology-netconf}]/node/node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=netconf-mdsal}]",
"error-message": "Data already exists"
}
]
}
}
]
}
}
}
The data-exists error is correctly captured for the second edit, but the status code does not reflect the error.
And the PATCH request for a NETCONF device has other issues.
For example, the following PATCH request to update/create/update configuration on a NETCONF node:
PATCH /rests/data/network-topology:network-topology/topology=topology-netconf/node=ncserver/yang-ext:mount HTTP/1.1
Accept: application/yang-data+json
Content-Type: application/yang-patch+json
{
"ietf-yang-patch:yang-patch": {
"patch-id": "patch1",
"edit": [
{
"edit-id": "edit1",
"operation": "merge",
"target": "/foo:foo",
"value": {
"foo:foo": {
"baz": "edit1"
}
}
},
{
"edit-id": "edit2",
"operation": "create",
"target": "/foo:foo",
"value": {
"foo:foo": {
"baz": "edit2"
}
}
},
{
"edit-id": "edit3",
"operation": "merge",
"target": "/foo:foo",
"value": {
"foo:foo": {
"baz": "edit3"
}
}
}
]
}
}
returns status code of 200 with the following yang-patch-status:
{
"ietf-yang-patch:yang-patch-status": {
"patch-id": "patch1",
"errors": {
"error": [
{
"error-type": "protocol",
"error-tag": "data-exists",
"error-message": "Data already exists"
}
]
},
"edit-status": {
"edit": [
{
"edit-id": "edit1",
"ok": [
null
]
},
{
"edit-id": "edit2",
"ok": [
null
]
},
{
"edit-id": "edit3",
"ok": [
null
]
}
]
}
}
}
The error is because of the second edit - it was trying to create a data resource which already exists. But the error information is in the global errors, errors right under yang-patch-status, while edit-status has ok for all 3 edits.
case global-errors {
uses rc:errors;
description
"This container will be present if global errors that
are unrelated to a specific edit occurred.";
}
So this response is very misleading - the yang-patch-status message implies that an error occurred after successful processing of all 3 edits.
—
NOTE
- For this PATCH request 3 <edit-config> RPC calls are sent to the device. Ideally the 3rd edit shouldn't take place since the second one failed although any changes made to the candidate datastore will be reverted with <discard-changes> before the transaction is closed. The following log shows the 3rd <edit-confg> and its response:
21:33:49.040 TRACE [globalWorkerGroup-3-4] RemoteDeviceId[name=ncserver, address=/127.0.0.1:830]: Matched request: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-8505"> <edit-config> <target> <candidate/> </target> <error-option>rollback-on-error</error-option> <config> <foo xmlns="urn:foo" xmlns:op="urn:ietf:params:xml:ns:netconf:base:1.0" op:operation="merge"> <baz>edit3</baz> </foo> </config> </edit-config> </rpc> to response: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-8505"> <ok/> </rpc-reply>
- When the device does not support the candidate datastore and only supports the running datastore, there is no easy way to restore the original configuration, and the following requirement on error handling is not guaranteed if a PATCH request has more than one edit.
container yang-patch { description "Represents a conceptual sequence of datastore edits, called a patch. Each patch is given a client-assigned patch identifier. Each edit MUST be applied in ascending order, and all edits MUST be applied. If any errors occur, then the target datastore MUST NOT be changed by the YANG Patch operation.
- split to
-
NETCONF-1197 Translate the patch request into a single edit-config
-
- Open
-
-
NETCONF-1176 Improve failed YANG patch error output
-
- Resolved
-
