[NETCONF-747] Unable execute YANG patch request when targeting augmented element Created: 11/Dec/20  Updated: 21/Jun/23  Resolved: 20/Mar/23

Status: Resolved
Project: netconf
Component/s: None
Affects Version/s: Magnesium SR2, 1.13.0, Aluminium SR1, 3.0.8, 4.0.5, 5.0.2
Fix Version/s: 3.0.9, 4.0.6, 5.0.3

Type: Bug Priority: Medium
Reporter: Samuel Kontris Assignee: Oleksandr Zharov
Resolution: Done Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File [NETCONF-747] Steps to reproduce.odt     Text File log.txt     File test-model-aug.yang     File test-model.yang    
Issue Links:
Issue split
split to NETCONF-911 JSON reader: Eliminate additional log... Confirmed

 Description   

Error 500 is returned when executing yang-patch request that targets augmented element.

Tested on master and stable/magnesium branch with simulated netconf device.

Tested models look like this (full models in attachments):

  container container-root {
    ...
    container container-lvl1 {
      ...
    }
  }
  augment /tm:container-root/tm:container-lvl1 {
    container container-aug {
      leaf leaf-aug {
        type string;
      }
      ...
    }
  }

YANG patch request:

{
    "ietf-yang-patch:yang-patch": {
        "patch-id": "test-patch",
        "comment": "comment",
        "edit": [
            {
                "edit-id": "edit1",
                "operation": "replace",
                "target": "/test-model:container-root/test-model:container-lvl1/test-model-aug:container-aug",
                "value": {
                    "container-aug": {
                        "leaf-aug": "data"
                    }
                }
            }
        ]
    }
}

Exception from logs on master branch (full logs in attachments):

14:27:21.286 WARN [qtp910831865-121] /rests/data/network-topology:network-topology/topology=topology-netconf/node=device/yang-ext:mount
javax.servlet.ServletException: javax.servlet.ServletException: java.lang.IllegalArgumentException: Could not find schema for node (test-ns-aug)container-aug in container container-aug
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:90) ~[?:?]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.28.v20200408]
	at org.eclipse.jetty.server.Server.handle(Server.java:500) ~[bundleFile:9.4.28.v20200408]
	...
Caused by: javax.servlet.ServletException: java.lang.IllegalArgumentException: Could not find schema for node (test-ns-aug)container-aug in container container-aug
	at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:432) ~[?:?]
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:370) ~[?:?]
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:389) ~[?:?]
    ...
Caused by: java.lang.IllegalArgumentException: Could not find schema for node (test-ns-aug)container-aug in container container-aug
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:441) ~[?:?]
	at org.opendaylight.yangtools.yang.data.impl.codec.SchemaTracker.getSchema(SchemaTracker.java:153) ~[?:?]
	at org.opendaylight.yangtools.yang.data.impl.codec.SchemaTracker.startContainerNode(SchemaTracker.java:233) ~[?:?]
    ...

Targeting `leaf-aug` directly (one layer lower) works OK:

                "target": "/test-model:container-root/test-model:container-lvl1/test-model-aug:container-aug/test-model-aug:leaf-aug",
                "value": {
                    "leaf-aug": "data"
                }

And targeting `container-lvl1` that's being augmented (one level higher) works too:

                "target": "/test-model:container-root/test-model:container-lvl1",
                "value": {
                    "container-lvl1": {
                        "container-aug": {
                            "leaf-aug": "data"
                        }
                    }
                }


 Comments   
Comment by Vratko Polak [ 11/Dec/20 ]

Does Netconf project have unit (or integration) tests to be run from maven that can detect this?

Comment by Robert Varga [ 11/Dec/20 ]

nope, as this is full-stack integration – hence subject to CSIT

Comment by Oleksandr Zharov [ 12/Sep/22 ]

Added updated steps to reproduce - you will need it on latest version since restconf-bierman is gone. Also I added unit test that can be used to check issue in my patch. Plus in that patch I also marked possible way to fix it. I failed to do it myself. My idea is related to NETCONF-631. So for MIX nodes there should be one additional step - taking child node of augmentation that is proper node and put this node into payload of transaction. Currently we sending augmentation and it fails one of checks.

Comment by Ivan Hrasko [ 09/Nov/22 ]

I would propose to go with: https://git.opendaylight.org/gerrit/c/netconf/+/102227 which uses the same logic as in JSON PATCH reader like it is used in JsonNormalizedNodeBodyReader. This behaviour is strange and we need to discover why we need to use additional logic when using JSON. This would require another tests/task.

Comment by Ivan Hrasko [ 10/Nov/22 ]

Task to investigate this: https://jira.opendaylight.org/browse/NETCONF-911

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