https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-513 netconf <p>Post and put via 8040 restconf have reinstated an old bug from the days of Lithium where they create a merge transaction with an empty Node as a data part.</p> <p>Merge with an empty data portion is a NOOP. This transaction should never be created in the first place.</p> <p>I am observing this with JSON RPC, but this will show up across any other mounted data resource. JSON RPC simply allows me to monitor what is coming out of ODL across a mount point.</p> NETCONF-513

8040 post and put result in spurious NOOPs to mounted resources

Bug Low Resolved Won't Do Anton Ivanov Anton Ivanov Fri, 23 Feb 2018 17:58:09 +0000 Fri, 15 Mar 2019 22:22:14 +0000 Mon, 1 Oct 2018 18:51:43 +0000 restconf-nb 0 3 <p>Can you add more detail?</p> <p>Some backhground:</p> <p>JSONRPC tranlates transactions originating from MDSAL more or less 1:1. So for each attempted operation in the SAL layer across the data broker there is a visible operation across JSON RPC.</p> <p>If we attempt PUT to <a href="http://127.0.0.1:8181/rests/data/jsonrpc:config/configured-endpoints=openswitch-1/yang-ext:mount/ietf-interfaces:interfaces/interface=e101-001-0" class="external-link" target="_blank" rel="nofollow noopener">http://127.0.0.1:8181/rests/data/jsonrpc:config/configured-endpoints=openswitch-1/yang-ext:mount/ietf-interfaces:interfaces/interface=e101-001-0</a> with the following body:</p> <p>{"interface":</p> { "name":"e101-001-0", "enabled":true, "speed":"100MBPS", "dell-interface:mode":"MODE_L2", "base-if-phy:learn-mode":"HW" } <p>}</p> <p>We get the following transaction sequence:</p> <p> </p> <p>1. Read. This simply should not be happening. PUT means "do as I say", why is it reading at all?</p> <p>{{INFO:root:&gt; {"jsonrpc":"2.0","id":1,"method":"read","params":["config","openswitch-1",{"ietf-interfaces:interfaces":{"interface":[</p> {"name":"e101-001-0"} <p>]}}]}}}<br/> <tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 1, "result": {"dell-interface:duplex": "full", "dell-interface:auto-negotiation": false, "base-if-phy:npu-id": 0, "name": "e101-001-0", "dell-interface:mode": "MODE_NONE", "dell-interface:speed": "0MBPS", "base-if-common:if-index": 3, "base-if-phy:port-id": 25, "enabled": false, "dell-interface:phys-address": "90:b1:1c:f4:ef:a0", "base-if-phy:phy-media": "AR_POPTICS_UNKNOWN", "base-if-phy:tagging-mode": "HYBRID", "base-if-phy:learn-mode": "HW", "dell-interface:fec": "off", "type": "iana-if-type:ethernetCsmacd", "dell-interface:oui": 6976381, "dell-interface:mtu": 1532</tt>}}</p> <p><tt>2. Allocate a read-write transaction</tt><br/> <tt>INFO:root:&gt; {"jsonrpc":"2.0","id":1,"method":"txid"</tt>}<br/> <tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 1, "result": "9da95d65-fac2-41bc-aec4-c0b063f52015"</tt>}</p> <p>3. Merge of an empty object. As far as meaningless churning this is probably exemplary - this is a clear NOOP.</p> <p><tt>INFO:root:&gt; {"jsonrpc":"2.0","id":2,"method":"merge","params":<span class="error">&#91;&quot;9da95d65-fac2-41bc-aec4-c0b063f52015&quot;,&quot;config&quot;,&quot;openswitch-1&quot;,{&quot;ietf-interfaces:interfaces&quot;:{}},{}&#93;</span></tt>}<br/> <tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 2, "result": null</tt>}</p> <p>4.  The actual put - this should have been No 2. 1 and 3 should have never been executed.</p> <p>INFO:root:&gt; {"jsonrpc":"2.0","id":3,"method":"put","params":["9da95d65-fac2-41bc-aec4-c0b063f52015","config","openswitch-1",{"ietf-interfaces:interfaces":{"interface":[</p> {"name":"e101-001-0"} <p>]}},{"name":"e101-001-0","enabled":true,"dell-interface:mode":"MODE_L2","dell-interface:speed":"100MBPS","base-if-phy:learn-mode":"HW"}]}<br/> INFO:root:&lt; {"jsonrpc": "2.0", "id": 3, "result": null}</p> <p><tt>5. Commit transaction.</tt><br/> <tt>INFO:root:&gt; {"jsonrpc":"2.0","id":4,"method":"commit","params":<span class="error">&#91;&quot;9da95d65-fac2-41bc-aec4-c0b063f52015&quot;&#93;</span></tt>}<tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 4, "result": true</tt>}</p> <p>POST is even "better".</p> <p>This is an trace of a POST to <a href="http://127.0.0.1:8181/restconf/config/jsonrpc:config/configured-endpoints/openswitch-1/yang-ext:mount/ietf-interfaces:interfaces/" class="external-link" target="_blank" rel="nofollow noopener">http://127.0.0.1:8181/restconf/config/jsonrpc:config/configured-endpoints/openswitch-1/yang-ext:mount/ietf-interfaces:interfaces/</a></p> <p>{"interface":</p> { "name":"br200", "type":"iana-if-type:l2vlan", "base-if-vlan:id":200, "dell-interface:untagged-ports":["e101-001-0","e101-002-0"], "enabled":true } <p>}</p> <p>1 First operation is exists() - that is correct behavior, so far so good</p> <p>{{INFO:root:&gt; {"jsonrpc":"2.0","id":1,"method":"exists","params":["config","openswitch-1",{"ietf-interfaces:interfaces":{"interface":[</p> {"name":"br200"} <p>]}}]}}}<tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 1, "result": false</tt>}</p> <p><tt>2. Second is allocate read-write transaction</tt><br/> <tt>INFO:root:&gt; {"jsonrpc":"2.0","id":2,"method":"txid"</tt>}<br/> <tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 2, "result": "cd6ba031-5840-4f34-885c-bb0d1ba2f5da"</tt>}</p> <p>{{3. After that ODL goes off the deep end for a while - not one. Two meaningless churn merges of an empty object }}<br/> <tt>INFO:root:&gt; {"jsonrpc":"2.0","id":3,"method":"merge","params":<span class="error">&#91;&quot;cd6ba031-5840-4f34-885c-bb0d1ba2f5da&quot;,&quot;config&quot;,&quot;openswitch-1&quot;,{&quot;ietf-interfaces:interfaces&quot;:{}},{}&#93;</span></tt>}<br/> <tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 3, "result": null</tt>}<br/> <tt>INFO:root:&gt; {"jsonrpc":"2.0","id":4,"method":"merge","params":<span class="error">&#91;&quot;cd6ba031-5840-4f34-885c-bb0d1ba2f5da&quot;,&quot;config&quot;,&quot;openswitch-1&quot;,{&quot;ietf-interfaces:interfaces&quot;:{}},{}&#93;</span></tt>}<br/> <tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 4, "result": null</tt>}</p> <p><tt>4. This is sort-a correct. I would have expected to see merge() here. However, because the item does not exist, put and merge yield the same result.</tt><br/> {{INFO:root:&gt; {"jsonrpc":"2.0","id":5,"method":"put","params":["cd6ba031-5840-4f34-885c-bb0d1ba2f5da","config","openswitch-1",{"ietf-interfaces:interfaces":{"interface":[</p> {"name":"br200"} <p>]}},{"name":"br200","base-if-vlan:id":200,"enabled":true,"dell-interface:untagged-ports":<span class="error">&#91;&quot;e101-002-0&quot;,&quot;e101-001-0&quot;&#93;</span>,"type":"iana-if-type:l2vlan"}]}}}<br/> <tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 5, "result": null</tt>}</p> <p><tt>5. Finally - commit transaction</tt><br/> <tt>INFO:root:&gt; {"jsonrpc":"2.0","id":6,"method":"commit","params":<span class="error">&#91;&quot;cd6ba031-5840-4f34-885c-bb0d1ba2f5da&quot;&#93;</span></tt>}<tt>INFO:root:&lt; {"jsonrpc": "2.0", "id": 6, "result": true</tt>}</p> <p>In both cases JSON RPC is the "messenger" - it simply shows what is coming out of MDSAL courtesy of Restconf translating an HTTP request. I would not expect MDSAL to breed requests or modify them in-transit so my suspicion is with restconf codec having some FSM issues.</p> <p>It looks like the merge is to ensure the parents exist via TransactionUtil.ensureParentsByMerge. This is necessary for at least the MD_SAL data store - it may not be for all mount point implementations but the restconf front-end doesn't know the difference. Is this behavior specific to the 8040 impl? I believe the draft02 impl should do the same thing. </p> <p>Also it doesn't create a separate transaction to do the parent merges - it creates one transaction to do all the operations. </p> <p> Is this really an issue for jsonrpc?</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=aivanov" class="user-hover" rel="aivanov">aivanov</a> any thoughts on last comment from <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a>?</p> <p>This was discussed as a part of several other discussions related to JSON RPC, database options for mdsal backends, etc.</p> <p>It is not an 8040 implementation bug and it will sort itself on its own as mdsal develops to include various alternative backends.</p> <p>You can close it.</p> Development Rank 0|i03aqf: