[OPNFLWPLUG-269] of-flow: sal-flow:update-flow return 400 Created: 09/Sep/14  Updated: 27/Sep/21  Resolved: 24/Sep/14

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Peter Gubka Assignee: Michal Rehak
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


External issue ID: 1765

 Description   

odl:
org.opendaylight.controller.version = 0.1
org.opendaylight.controller.build.scm.version = 15e9db7d90e46f014aeba760263623094bc48f14
org.opendaylight.controller.build.user = jenkins-controller
org.opendaylight.controller.build.workspace = **********
org.opendaylight.controller.build.timestamp = 1410248111419
org.opendaylight.controller.build.machine = **********

when trying to use /restconf/operations/sal-flow:update-flow i get 400, the same xml works for add-flow, so the problem should be somewhere else.

POST /restconf/operations/sal-flow:update-flow HTTP/1.1
Host: 10.25.2.9:8080
Content-Length: 899
Accept-Encoding: gzip, deflate
Accept: /
User-Agent: python-requests/2.3.0 CPython/2.7.3 Linux/3.10.12-100.fc18.x86_64
Content-Type: application/xml
Authorization: Basic YWRtaW46YWRtaW4=

<input xmlns="urn:opendaylight:flow:service">
<strict>false</strict>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<drop-action />
</action>
</apply-actions>
</instruction>
</instructions>
<table_id>2</table_id>
<cookie_mask>255</cookie_mask>
<installHw>false</installHw>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-destination>10.0.1.0/24</ipv4-destination>
</match>
<cookie>1</cookie>
<flow-name>FooXf1</flow-name>
<priority>1</priority>
<barrier>false</barrier>
<node xmlns:inv="urn:opendaylight:inventory">/inv:nodes/inv:node[inv:id="openflow:1"]</node></input>

HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Content-Type: /
Transfer-Encoding: chunked
Date: Tue, 09 Sep 2014 09:29:51 GMT
Connection: close

146
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<error>
<error-type>application</error-type>
<error-tag>unknown-element</error-tag>
<error-message>Schema node "strict" was not found in module.</error-message>
</error>
</errors>



 Comments   
Comment by Michal Rehak [ 16/Sep/14 ]

This is kind of expected behavior. By using rpc to update flow there is different input model (dataStore takes care of creating it if some flow data get changed).

In order for this update via rpc to work you need following xml:
(I changed action (drop -> dec-nw-ttl)). In case that match/priority is changed this does not work correctly - flow gets removed from device. In case of action change it works.

<input xmlns="urn:opendaylight:flow:service">
<flow-ref xmlns:inv="urn:opendaylight:inventory">/inv:nodes/inv:node[inv:id="openflow:1"]/inv:table[inv:id=2]/inv:flow[inv:id=1765]</flow-ref>

<node xmlns:inv="urn:opendaylight:inventory">/inv:nodes/inv:node[inv:id="openflow:1"]</node>

<original-flow>
<strict>false</strict>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<drop-action />
</action>
</apply-actions>
</instruction>
</instructions>
<table_id>2</table_id>
<cookie_mask>255</cookie_mask>
<installHw>false</installHw>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-destination>10.0.1.0/24</ipv4-destination>
</match>
<cookie>2</cookie>
<flow-name>FooXf1</flow-name>
<priority>1</priority>
<barrier>false</barrier>
</original-flow>

<updated-flow>
<strict>false</strict>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<dec-nw-ttl/>
</action>
</apply-actions>
</instruction>
</instructions>
<table_id>2</table_id>
<cookie_mask>255</cookie_mask>
<installHw>false</installHw>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-destination>10.0.1.0/24</ipv4-destination>
</match>
<cookie>2</cookie>
<flow-name>FooXf1</flow-name>
<priority>1</priority>
<barrier>false</barrier>
</updated-flow>

</input>

Comment by Peter Gubka [ 19/Sep/14 ]

not am issue any longer, input updated

Comment by Jamo Luhrsen [ 24/Sep/14 ]

Verified this in RC2:
distribution-karaf-0.2.0-Helium-RC2.zip

regression automation (previously disabled) will now be enabled in integration test code.

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