Details
-
Bug
-
Status: Resolved
-
High
-
Resolution: Won't Do
-
Aluminium-SR1
-
None
-
None
-
None
Description
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:
Original config:
REST GET /restconf/operational/opendaylight-inventory:nodes/node/openflow:123456789/table/0/flow/101
<flow xmlns="urn:opendaylight:flow:inventory"> <id>101</id> <table_id>0</table_id> <flow-statistics xmlns="urn:opendaylight:flow:statistics"> <duration> <second>729</second> <nanosecond>245000000</nanosecond> </duration> <packet-count>249</packet-count> <byte-count>17059</byte-count> </flow-statistics> <priority>3</priority> <hard-timeout>0</hard-timeout> <match> <in-port>1</in-port> <ethernet-match> <ethernet-type> <type>2048</type> </ethernet-type> </ethernet-match> </match> <cookie_mask>0</cookie_mask> <cookie>0</cookie> <flags/> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>4</order> <set-field> <ipv4-destination>10.0.0.10/32</ipv4-destination> </set-field> </action> <action> <order>5</order> <output-action> <output-node-connector>3</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>6</order> <set-field> <ethernet-match> <ethernet-destination> <address>00:00:00:aa:00:56</address> </ethernet-destination> </ethernet-match> </set-field> </action> <action> <order>7</order> <set-field> <ipv4-destination>10.0.3.10/32</ipv4-destination> </set-field> </action> <action> <order>0</order> <set-field> <ethernet-match> <ethernet-destination> <address>00:00:00:aa:00:54</address> </ethernet-destination> </ethernet-match> </set-field> </action> <action> <order>1</order> <set-field> <ipv4-destination>10.0.1.10/32</ipv4-destination> </set-field> </action> <action> <order>2</order> <output-action> <output-node-connector>2</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>3</order> <set-field> <ethernet-match> <ethernet-destination> <address>00:00:00:aa:00:55</address> </ethernet-destination> </ethernet-match> </set-field> </action> <action> <order>8</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>9</order> <set-nw-ttl-action> <nw-ttl>7</nw-ttl> </set-nw-ttl-action> </action> <action> <order>10</order> <set-field> <ipv4-destination>10.0.6.10/32</ipv4-destination> </set-field> </action> <action> <order>11</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> <idle-timeout>0</idle-timeout> </flow>
Notice
- There are 11 actions
- The order is 0-11
- (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...)
Next I delete off action order 0:
REST DELETE restconf/config/opendaylight-inventory:nodes/node/openflow:123456789/table/0/flow/101/instructions/instruction/0/apply-actions/action/0
Returns 200
Now the config looks like this:
REST GET /restconf/operational/opendaylight-inventory:nodes/node/openflow:123456789/table/0/flow/101
<flow xmlns="urn:opendaylight:flow:inventory"> <id>101</id> <table_id>0</table_id> <flow-statistics xmlns="urn:opendaylight:flow:statistics"> <duration> <second>26</second> <nanosecond>701000000</nanosecond> </duration> <packet-count>249</packet-count> <byte-count>17059</byte-count> </flow-statistics> <priority>3</priority> <hard-timeout>0</hard-timeout> <match> <in-port>1</in-port> <ethernet-match> <ethernet-type> <type>2048</type> </ethernet-type> </ethernet-match> </match> <cookie_mask>0</cookie_mask> <cookie>0</cookie> <flags/> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>4</order> <output-action> <output-node-connector>3</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>5</order> <set-field> <ethernet-match> <ethernet-destination> <address>00:00:00:aa:00:56</address> </ethernet-destination> </ethernet-match> </set-field> </action> <action> <order>6</order> <set-field> <ipv4-destination>10.0.3.10/32</ipv4-destination> </set-field> </action> <action> <order>7</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>0</order> <set-field> <ipv4-destination>10.0.1.10/32</ipv4-destination> </set-field> </action> <action> <order>1</order> <output-action> <output-node-connector>2</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>2</order> <set-field> <ethernet-match> <ethernet-destination> <address>00:00:00:aa:00:55</address> </ethernet-destination> </ethernet-match> </set-field> </action> <action> <order>3</order> <set-field> <ipv4-destination>10.0.0.10/32</ipv4-destination> </set-field> </action> <action> <order>8</order> <set-nw-ttl-action> <nw-ttl>7</nw-ttl> </set-nw-ttl-action> </action> <action> <order>9</order> <set-field> <ipv4-destination>10.0.6.10/32</ipv4-destination> </set-field> </action> <action> <order>10</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> <idle-timeout>0</idle-timeout> </flow>
First some notes:
- The order numbers has changed. I.e., what was previously order 9 is now order 8.
- There is still an order 0
- The highest order number is now 10 (it was 11)
- Can I re-run the above delete command and delete the new action-order 0?
Here is a bit of a diff to make it easier to compare the above:
diff -r < <order>5</order> 43c37 < <order>6</order> --- > <order>5</order> 53c47 < <order>7</order> --- > <order>6</order> 59,66c53,57 < <set-field> < <ethernet-match> < <ethernet-destination> < <address>00:00:00:aa:00:54</address> < </ethernet-destination> < </ethernet-match> < </set-field> --- 99c89 < <order>9</order> --- > <order>8</order> 105c95 < <order>10</order> --- > <order>9</order> 111c101 < <order>11</order> --- > <order>10</order>
Okay, so now what was originally action/1 is now action/0.
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:
REST DELETE restconf/config/opendaylight-inventory:nodes/node/openflow:123456789/table/0/flow/101/instructions/instruction/0/apply-actions/action/0
Returns 409:
{
"errors": {
"error": [
{
"error-type": "protocol",
"error-tag": "data-missing",
"error-message": "Data does not exist for 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)switch-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}]"
}
]
}
}
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:
REST DELETE restconf/config/opendaylight-inventory:nodes/node/openflow:123456789/table/0/flow/101/instructions/instruction/0/apply-actions/action/1
Returns 200
And the resulting config is:
REST GET /restconf/operational/opendaylight-inventory:nodes/node/openflow:123456789/table/0/flow/101
<flow xmlns="urn:opendaylight:flow:inventory"> <id>101</id> <table_id>0</table_id> <flow-statistics xmlns="urn:opendaylight:flow:statistics"> <duration> <second>2</second> <nanosecond>7000000</nanosecond> </duration> <packet-count>249</packet-count> <byte-count>17059</byte-count> </flow-statistics> <priority>3</priority> <hard-timeout>0</hard-timeout> <match> <in-port>1</in-port> <ethernet-match> <ethernet-type> <type>2048</type> </ethernet-type> </ethernet-match> </match> <cookie_mask>0</cookie_mask> <cookie>0</cookie> <flags/> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>4</order> <set-field> <ethernet-match> <ethernet-destination> <address>00:00:00:aa:00:56</address> </ethernet-destination> </ethernet-match> </set-field> </action> <action> <order>5</order> <set-field> <ipv4-destination>10.0.3.10/32</ipv4-destination> </set-field> </action> <action> <order>6</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>7</order> <set-nw-ttl-action> <nw-ttl>7</nw-ttl> </set-nw-ttl-action> </action> <action> <order>0</order> <output-action> <output-node-connector>2</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>1</order> <set-field> <ethernet-match> <ethernet-destination> <address>00:00:00:aa:00:55</address> </ethernet-destination> </ethernet-match> </set-field> </action> <action> <order>2</order> <set-field> <ipv4-destination>10.0.0.10/32</ipv4-destination> </set-field> </action> <action> <order>3</order> <output-action> <output-node-connector>3</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>8</order> <set-field> <ipv4-destination>10.0.6.10/32</ipv4-destination> </set-field> </action> <action> <order>9</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> <idle-timeout>0</idle-timeout> </flow>
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).
So internally, the action-order values keep their original value, even though when I get-config, the order numbers are sequential.
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.
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.
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.
