Operating System: Linux
Platform: PC

Problem is in way how you are combining HTTP method POST and data payload.

Suppose following data tree: /el1/el2/el3/.../elN
When you are using POST then:

• uri: /el1/el2/
• payload: /el3/el4/..../elN

In your comment there is uri ......./table/0/flow/1234 but data also contains flow element with <id>1234</id>

Such using is possible in PUT where

• uri: /el1/el2/el3
• payload: /el3/el4/....
  and here is validating equality (for list element) of all keys in URI with keys in payload.

Hi Jozef,

From restconf perspective this is okay, but it's resulting in incorrect functional behavior. The intent of the bug was to validate the uri data with the body data by the entity that is responsible for installing these flows. I believe its FRM, so it should validate that the flow its going to install in the switch is also stored at the expected location in the data store. If it fails in doing that, network state and data store state is not going to be in sync and that can result in inconsistent behavior of the whole system.

Thanks
Anil

https://git.opendaylight.org/gerrit/#/c/10024/

Above mentioned patch is merged so i tried to test it. So i tested following two scenario (using the example flow i mentioned in bug report)

URI: http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/1235 (flow id is 1235)

But in body flow id is 1234 and it resulted in following output

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<errors
xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<error>
<error-type>protocol</error-type>
<error-tag>invalid-value</error-tag>
<error-message>The value '1235' for key 'id' specified in the URI doesn't match the value '1234' specified in the message body. </error-message>
</error>
</errors>

So this is correct behavior. I tried following second scenario

URI: URI: http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/1234 (table id is 2)

but in body table-id is 0. When i fire this rest call, postman gives me response status 200 OK, but i do see that controller spit following error

ERROR o.o.c.frm.impl.FlowForwarder - TableID in URI tableId=0 and in palyload tableId=2 is not same.

BUT i can see this flow in config data store under /table/2/flow/1234.

is this expected behavior ?

Hi,

I believe this behavior is correct.

In the first case, restconf compared keys from the path with keys defined in the payload and found a difference -> this is clearly a mistake and you will get exception when you will try to store flow like this in data store -> you receive error.

In the second case, table id in the flow is not part of the key so you didn't get exception. From restconf/data store standpoint this payload is valid. (table id is just one of the parameters of the flow and there is no reference to the parent Table id) But, as you can see in second scenario error was thrown by forwarding rules manager -> this flow didn't pass forwarding rules manager validation and was not sent to the device.
There is nothing stopping you from creating invalid flow configuration in config data store. As you said, it is role of plugins that will try to work with this flow (FRM in this case) to validate if flow parameters are sane before sending them to device. You are responsible for removal/modification of this incorrect flow in the config data store.

I think this bug is fixed because your flow will not get to the device unless you correct your table id -> misbehavior that you described when you created this bug is fixed.

Marking as fixed.

Related bug for flow config table_id mismatch:
https://bugs.opendaylight.org/show_bug.cgi?id=1810

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL.