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/OPNFLWPLUG-1115 OpenFlowPlugin <p>I have found that when deleting an element in a config (specifically in my case, an OpenFlow action) a re-sequencing of keys occurs and I am unable to perform the delete again. This is best shown with an example:</p> <p>Original config:</p> <p><tt>REST GET /restconf/operational/opendaylight-inventory:nodes/node/openflow:123456789</tt>/table/0/flow/101</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> &lt;flow xmlns=<span class="code-quote">"urn:opendaylight:flow:inventory"</span>&gt; &lt;id&gt;101&lt;/id&gt; &lt;table_id&gt;0&lt;/table_id&gt; &lt;flow-statistics xmlns=<span class="code-quote">"urn:opendaylight:flow:statistics"</span>&gt; &lt;duration&gt; &lt;second&gt;729&lt;/second&gt; &lt;nanosecond&gt;245000000&lt;/nanosecond&gt; &lt;/duration&gt; &lt;packet-count&gt;249&lt;/packet-count&gt; &lt;<span class="code-object">byte</span>-count&gt;17059&lt;/<span class="code-object">byte</span>-count&gt; &lt;/flow-statistics&gt; &lt;priority&gt;3&lt;/priority&gt; &lt;hard-timeout&gt;0&lt;/hard-timeout&gt; &lt;match&gt; &lt;in-port&gt;1&lt;/in-port&gt; &lt;ethernet-match&gt; &lt;ethernet-type&gt; &lt;type&gt;2048&lt;/type&gt; &lt;/ethernet-type&gt; &lt;/ethernet-match&gt; &lt;/match&gt; &lt;cookie_mask&gt;0&lt;/cookie_mask&gt; &lt;cookie&gt;0&lt;/cookie&gt; &lt;flags/&gt; &lt;instructions&gt; &lt;instruction&gt; &lt;order&gt;0&lt;/order&gt; &lt;apply-actions&gt; &lt;action&gt; &lt;order&gt;4&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.0.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;5&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;3&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;6&lt;/order&gt; &lt;set-field&gt; &lt;ethernet-match&gt; &lt;ethernet-destination&gt; &lt;address&gt;00:00:00:aa:00:56&lt;/address&gt; &lt;/ethernet-destination&gt; &lt;/ethernet-match&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;7&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.3.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;0&lt;/order&gt; &lt;set-field&gt; &lt;ethernet-match&gt; &lt;ethernet-destination&gt; &lt;address&gt;00:00:00:aa:00:54&lt;/address&gt; &lt;/ethernet-destination&gt; &lt;/ethernet-match&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;1&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.1.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;2&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;2&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;3&lt;/order&gt; &lt;set-field&gt; &lt;ethernet-match&gt; &lt;ethernet-destination&gt; &lt;address&gt;00:00:00:aa:00:55&lt;/address&gt; &lt;/ethernet-destination&gt; &lt;/ethernet-match&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;8&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;4&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;9&lt;/order&gt; &lt;set-nw-ttl-action&gt; &lt;nw-ttl&gt;7&lt;/nw-ttl&gt; &lt;/set-nw-ttl-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;10&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.6.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;11&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;4&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;/apply-actions&gt; &lt;/instruction&gt; &lt;/instructions&gt; &lt;idle-timeout&gt;0&lt;/idle-timeout&gt; &lt;/flow&gt; </pre> </div></div> <p> </p> <p><b>Notice</b></p> <ul> <li>There are 11 actions</li> <li>The order is 0-11</li> <li>(Although not part of the question, when I submit the config, if I use my own order values, ODL internally changes them to 0...11 based on the sorted order of my original order values. I.e., if my order values were originally 100, 105, 111, 200, it would get renamed to 0, 1, 2, 3...)</li> </ul> <p>Next I delete off action order 0:</p> <p><tt>REST DELETE restconf/config/opendaylight-inventory:nodes/node/openflow:</tt><tt>123456789</tt>/table/0/flow/101/instructions/instruction/0/apply-actions/action/0</p> <p><tt>Returns 200</tt></p> <p>Now the config looks like this:</p> <p><tt>REST GET /restconf/operational/opendaylight-inventory:nodes/node/openflow:</tt><tt>123456789</tt>/table/0/flow/101</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> &lt;flow xmlns=<span class="code-quote">"urn:opendaylight:flow:inventory"</span>&gt; &lt;id&gt;101&lt;/id&gt; &lt;table_id&gt;0&lt;/table_id&gt; &lt;flow-statistics xmlns=<span class="code-quote">"urn:opendaylight:flow:statistics"</span>&gt; &lt;duration&gt; &lt;second&gt;26&lt;/second&gt; &lt;nanosecond&gt;701000000&lt;/nanosecond&gt; &lt;/duration&gt; &lt;packet-count&gt;249&lt;/packet-count&gt; &lt;<span class="code-object">byte</span>-count&gt;17059&lt;/<span class="code-object">byte</span>-count&gt; &lt;/flow-statistics&gt; &lt;priority&gt;3&lt;/priority&gt; &lt;hard-timeout&gt;0&lt;/hard-timeout&gt; &lt;match&gt; &lt;in-port&gt;1&lt;/in-port&gt; &lt;ethernet-match&gt; &lt;ethernet-type&gt; &lt;type&gt;2048&lt;/type&gt; &lt;/ethernet-type&gt; &lt;/ethernet-match&gt; &lt;/match&gt; &lt;cookie_mask&gt;0&lt;/cookie_mask&gt; &lt;cookie&gt;0&lt;/cookie&gt; &lt;flags/&gt; &lt;instructions&gt; &lt;instruction&gt; &lt;order&gt;0&lt;/order&gt; &lt;apply-actions&gt; &lt;action&gt; &lt;order&gt;4&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;3&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;5&lt;/order&gt; &lt;set-field&gt; &lt;ethernet-match&gt; &lt;ethernet-destination&gt; &lt;address&gt;00:00:00:aa:00:56&lt;/address&gt; &lt;/ethernet-destination&gt; &lt;/ethernet-match&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;6&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.3.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;7&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;4&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;0&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.1.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;1&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;2&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;2&lt;/order&gt; &lt;set-field&gt; &lt;ethernet-match&gt; &lt;ethernet-destination&gt; &lt;address&gt;00:00:00:aa:00:55&lt;/address&gt; &lt;/ethernet-destination&gt; &lt;/ethernet-match&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;3&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.0.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;8&lt;/order&gt; &lt;set-nw-ttl-action&gt; &lt;nw-ttl&gt;7&lt;/nw-ttl&gt; &lt;/set-nw-ttl-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;9&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.6.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;10&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;4&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;/apply-actions&gt; &lt;/instruction&gt; &lt;/instructions&gt; &lt;idle-timeout&gt;0&lt;/idle-timeout&gt; &lt;/flow&gt; </pre> </div></div> <p> </p> <p> </p> <p><b>First some notes:</b></p> <ul> <li>The order numbers has changed. I.e., what was previously order 9 is now order 8.</li> <li>There is still an order 0</li> <li>The highest order number is now 10 (it was 11)</li> <li>Can I re-run the above delete command and delete the new action-order 0?</li> </ul> <p> </p> <p>Here is a bit of a diff to make it easier to compare the above:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> diff -r &lt; &lt;order&gt;5&lt;/order&gt; 43c37 &lt; &lt;order&gt;6&lt;/order&gt; --- &gt; &lt;order&gt;5&lt;/order&gt; 53c47 &lt; &lt;order&gt;7&lt;/order&gt; --- &gt; &lt;order&gt;6&lt;/order&gt; 59,66c53,57 &lt; &lt;set-field&gt; &lt; &lt;ethernet-match&gt; &lt; &lt;ethernet-destination&gt; &lt; &lt;address&gt;00:00:00:aa:00:54&lt;/address&gt; &lt; &lt;/ethernet-destination&gt; &lt; &lt;/ethernet-match&gt; &lt; &lt;/set-field&gt; --- 99c89 &lt; &lt;order&gt;9&lt;/order&gt; --- &gt; &lt;order&gt;8&lt;/order&gt; 105c95 &lt; &lt;order&gt;10&lt;/order&gt; --- &gt; &lt;order&gt;9&lt;/order&gt; 111c101 &lt; &lt;order&gt;11&lt;/order&gt; --- &gt; &lt;order&gt;10&lt;/order&gt; </pre> </div></div> <p>Okay, so now what was originally action/1 is now action/0. </p> <p> </p> <p>Here is the bug, I want to now delete this new action/0. Since the order value has changed to 0, re-run my REST DELETE command:</p> <p><tt>REST DELETE restconf/config/opendaylight-inventory:nodes/node/openflow:</tt><tt>123456789</tt>/table/0/flow/101/instructions/instruction/0/apply-actions/action/0</p> <p><tt>Returns 409:</tt></p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> { <span class="code-quote">"errors"</span>: { <span class="code-quote">"error"</span>: [ { <span class="code-quote">"error-type"</span>: <span class="code-quote">"protocol"</span>, <span class="code-quote">"error-tag"</span>: <span class="code-quote">"data-missing"</span>, <span class="code-quote">"error-message"</span>: <span class="code-quote">"Data does not exist <span class="code-keyword">for</span> path: /(urn:opendaylight:inventory?revision=2013-08-19)nodes/node/node[{(urn:opendaylight:inventory?revision=2013-08-19)id=openflow:257642806997568}]/AugmentationIdentifier{childNames=[(urn:opendaylight:flow:inventory?revision=2013-08-19)supported-match-types, (urn:opendaylight:flow:inventory?revision=2013-08-19)supported-instructions, (urn:opendaylight:flow:inventory?revision=2013-08-19)supported-actions, (urn:opendaylight:flow:inventory?revision=2013-08-19)<span class="code-keyword">switch</span>-features, (urn:opendaylight:flow:inventory?revision=2013-08-19)manufacturer, (urn:opendaylight:flow:inventory?revision=2013-08-19)hardware, (urn:opendaylight:flow:inventory?revision=2013-08-19)software, (urn:opendaylight:flow:inventory?revision=2013-08-19)serial-number, (urn:opendaylight:flow:inventory?revision=2013-08-19)description, (urn:opendaylight:flow:inventory?revision=2013-08-19)port-number, (urn:opendaylight:flow:inventory?revision=2013-08-19)ip-address, (urn:opendaylight:flow:inventory?revision=2013-08-19)meter, (urn:opendaylight:flow:inventory?revision=2013-08-19)stale-meter, (urn:opendaylight:flow:inventory?revision=2013-08-19)group, (urn:opendaylight:flow:inventory?revision=2013-08-19)stale-group, (urn:opendaylight:flow:inventory?revision=2013-08-19)table, (urn:opendaylight:flow:inventory?revision=2013-08-19)table-features]}/(urn:opendaylight:flow:inventory?revision=2013-08-19)table/table[{(urn:opendaylight:flow:inventory?revision=2013-08-19)id=0}]/flow/flow[{(urn:opendaylight:flow:inventory?revision=2013-08-19)id=101}]/instructions/instruction/instruction[{(urn:opendaylight:flow:inventory?revision=2013-08-19)order=0}]/instruction/apply-actions/action/action[{(urn:opendaylight:flow:inventory?revision=2013-08-19)order=0}]"</span> } ] } } </pre> </div></div> <p>It appears internally to ODL and its internal config, it doesn't acknowledge action/0. Internally, it still sees it as action/1. When I retry that delete command but with action/1 it works:</p> <p><tt>REST DELETE restconf/config/opendaylight-inventory:nodes/node/openflow:</tt><tt>123456789</tt>/table/0/flow/101/instructions/instruction/0/apply-actions/action/1</p> <p><tt>Returns 200</tt></p> <p>And the resulting config is:</p> <p><tt>REST GET /restconf/operational/opendaylight-inventory:nodes/node/openflow:</tt><tt>123456789</tt>/table/0/flow/101</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> &lt;flow xmlns=<span class="code-quote">"urn:opendaylight:flow:inventory"</span>&gt; &lt;id&gt;101&lt;/id&gt; &lt;table_id&gt;0&lt;/table_id&gt; &lt;flow-statistics xmlns=<span class="code-quote">"urn:opendaylight:flow:statistics"</span>&gt; &lt;duration&gt; &lt;second&gt;2&lt;/second&gt; &lt;nanosecond&gt;7000000&lt;/nanosecond&gt; &lt;/duration&gt; &lt;packet-count&gt;249&lt;/packet-count&gt; &lt;<span class="code-object">byte</span>-count&gt;17059&lt;/<span class="code-object">byte</span>-count&gt; &lt;/flow-statistics&gt; &lt;priority&gt;3&lt;/priority&gt; &lt;hard-timeout&gt;0&lt;/hard-timeout&gt; &lt;match&gt; &lt;in-port&gt;1&lt;/in-port&gt; &lt;ethernet-match&gt; &lt;ethernet-type&gt; &lt;type&gt;2048&lt;/type&gt; &lt;/ethernet-type&gt; &lt;/ethernet-match&gt; &lt;/match&gt; &lt;cookie_mask&gt;0&lt;/cookie_mask&gt; &lt;cookie&gt;0&lt;/cookie&gt; &lt;flags/&gt; &lt;instructions&gt; &lt;instruction&gt; &lt;order&gt;0&lt;/order&gt; &lt;apply-actions&gt; &lt;action&gt; &lt;order&gt;4&lt;/order&gt; &lt;set-field&gt; &lt;ethernet-match&gt; &lt;ethernet-destination&gt; &lt;address&gt;00:00:00:aa:00:56&lt;/address&gt; &lt;/ethernet-destination&gt; &lt;/ethernet-match&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;5&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.3.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;6&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;4&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;7&lt;/order&gt; &lt;set-nw-ttl-action&gt; &lt;nw-ttl&gt;7&lt;/nw-ttl&gt; &lt;/set-nw-ttl-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;0&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;2&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;1&lt;/order&gt; &lt;set-field&gt; &lt;ethernet-match&gt; &lt;ethernet-destination&gt; &lt;address&gt;00:00:00:aa:00:55&lt;/address&gt; &lt;/ethernet-destination&gt; &lt;/ethernet-match&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;2&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.0.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;3&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;3&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;8&lt;/order&gt; &lt;set-field&gt; &lt;ipv4-destination&gt;10.0.6.10/32&lt;/ipv4-destination&gt; &lt;/set-field&gt; &lt;/action&gt; &lt;action&gt; &lt;order&gt;9&lt;/order&gt; &lt;output-action&gt; &lt;output-node-connector&gt;4&lt;/output-node-connector&gt; &lt;max-length&gt;60&lt;/max-length&gt; &lt;/output-action&gt; &lt;/action&gt; &lt;/apply-actions&gt; &lt;/instruction&gt; &lt;/instructions&gt; &lt;idle-timeout&gt;0&lt;/idle-timeout&gt; &lt;/flow&gt; </pre> </div></div> <p>Look close and you see that action/0 is what was originally action/2 and also notice that the highest action order number is 9 (it was 11 originally).</p> <p> </p> <p>So internally, the action-order values keep their original value, even though when I get-config, the order numbers are sequential.</p> <p> </p> <p>Goal: when running a get-config, I should be able to reference the action/order value as seen by the current get-config. I do not have a way to track the original order values and I believe maintaining the original order value would mean maintaining old states of the system. </p> <p> </p> <p>Also, as mentioned earlier, the order numbers get overridden by ODL. I.e., if my order values were 123, 150, 155 it will get renumbered to 0, 1, 2. This doesn't bother me per-se, I can work around that, but I need to be able to reference the order values as given by the current get-config query. </p> <p> </p> <p>This issue is a blocker for us in that we need to be able to do micro edits to our config without sweeping deletes and replaces of entire flows. </p> OPNFLWPLUG-1115

Inconsistencies Deleting Elements in a Config

Bug High Resolved Won't Do Unassigned Eric Sender Wed, 16 Dec 2020 19:12:34 +0000 Fri, 18 Nov 2022 07:20:11 +0000 Fri, 18 Nov 2022 07:20:11 +0000 Aluminium-SR1 0 3 <p>This looks like a translation issue in OpenFlow – note neither RESTCONF nor datastore can perform data transformations (i.e. changing 'order'). 'order' is a construct defined by OFP YANG models.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=esender" class="user-hover" rel="esender">esender</a> can you add the before and after contents of the config datastore, please?</p> <p> </p> <p>I actually do have that pasted in the issue description, including a diff between the before and after. </p> <p>The full config would be huge, I narrowed the config to the specific flow in question. Did you want to see the full config? </p> <p>I was not sure what I was looking for exactly, now I think I know. What does</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">REST GET restconf/config/opendaylight-inventory:nodes/node/openflow:123456789/table/0/flow/101/instructions/instruction/0/apply-actions/action/0</pre> </div></div> <p>return?</p> <p>Also, there should be a stack trace in karaf.log to go with that 409, I think. Can you attach that, too?</p> <p>I don't see a stacktrace unforunatly, even in DEBUG logging mode.</p> <p>Look at:</p> <ul> <li>Line 4689 - start of REST Delete</li> <li>Line 4950 - "409" response noted. </li> </ul> <p><a href="https://jira.opendaylight.org/secure/attachment/16001/karaf.log.gz" class="external-link" rel="nofollow">https://jira.opendaylight.org/secure/attachment/16001/karaf.log.gz</a></p> <p>(If there is an alternative to DELETE that I could try, I'd like to. I am playing with the REST PATCH endpoint but I am having trouble getting it to work and I can't find any good examples of using REST PATCH)</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=esender" class="user-hover" rel="esender">esender</a> All the flow information above is from the operational datastore, which is populated by OpenFlow Plugin. Since OpenFlow itself does not have an explicit attribute <tt>order</tt> for ordering of actions, it's just an ordered list, the attribute is populated by the plugin incrementing from 0. So if you look at the configuration datastore, you will see different <tt>order</tt> values, and the values in the configuration datastore are not modified by the plugin.</p> <p>For example, I created a flow with 4 actions - note that the order values are <tt>100</tt>, <tt>101</tt>, <tt>102</tt>, <tt>103</tt>. Also, the URL is for the RFC8040 implementation, not for Bierman02 draft that starts with <tt>/restconf</tt>.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>GET /rests/data/opendaylight-inventory:nodes/node=openflow%3A1/flow-node-inventory:table=1/flow=1/instructions/instruction=0/apply-actions?content=config { "flow-node-inventory:apply-actions": { "action": [ { "order": 100, "output-action": { "output-node-connector": "LOCAL" } }, { "order": 101, "output-action": { "output-node-connector": "1" } }, { "order": 102, "output-action": { "output-node-connector": "2" } }, { "order": 103, "output-action": { "output-node-connector": "3" } } ] } } </pre> </div></div> <p>From the operational data store I get this - note that the order values are <tt>0</tt>, <tt>1</tt>, <tt>2</tt>, <tt>3</tt>.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>GET /rests/data/opendaylight-inventory:nodes/node=openflow%3A1/flow-node-inventory:table=1/flow=1/instructions/instruction=0/apply-actions?content=nonconfig { "flow-node-inventory:apply-actions": { "action": [ { "order": 0, "output-action": { "max-length": 0, "output-node-connector": "LOCAL" } }, { "order": 1, "output-action": { "max-length": 0, "output-node-connector": "1" } }, { "order": 2, "output-action": { "max-length": 0, "output-node-connector": "2" } }, { "order": 3, "output-action": { "max-length": 0, "output-node-connector": "3" } } ] } } </pre> </div></div> <p>However, in general the inventory data model is not very compatible with RFC8040 - which allows getting both configuration &amp; operational data together.</p> <p>For example, the following REST call</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>GET /rests/data/opendaylight-inventory:nodes/node=openflow%3A1/flow-node-inventory:table=1/flow=1/instructions/instruction=0/apply-actions </pre> </div></div> <p>or</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>GET /rests/data/opendaylight-inventory:nodes/node=openflow%3A1/flow-node-inventory:table=1/flow=1/instructions/instruction=0/apply-actions?content=all </pre> </div></div> <p>returns the following combing both configuration &amp; operational data.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>{ "flow-node-inventory:apply-actions": { "action": [ { "order": 0, "output-action": { "max-length": 0, "output-node-connector": "LOCAL" } }, { "order": 1, "output-action": { "max-length": 0, "output-node-connector": "1" } }, { "order": 2, "output-action": { "max-length": 0, "output-node-connector": "2" } }, { "order": 3, "output-action": { "max-length": 0, "output-node-connector": "3" } }, { "order": 100, "output-action": { "output-node-connector": "LOCAL" } }, { "order": 101, "output-action": { "output-node-connector": "1" } }, { "order": 102, "output-action": { "output-node-connector": "2" } }, { "order": 103, "output-action": { "output-node-connector": "3" } } ] } } </pre> </div></div> <p>And this obviously is really misleading at best.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=sangwookha" class="user-hover" rel="sangwookha">sangwookha</a> - thank you for this. I did discover this distinction between the config and operational datastore (a year ago I was that much more newb to netconf). </p> <p>Our team engineered our solution with this understanding. We aren't quite able to micro-edit aspects of the operational flow, but we are okay doing full replacements instead. </p> Development Rank 0|i03wm7: