[OPNFLWPLUG-533] Rest Post operation is not working for group Created: 11/Aug/15  Updated: 27/Sep/21  Resolved: 23/Aug/16

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

Type: Bug
Reporter: Anpukarasi Muthukumaran Assignee: Abbas P Pareedkunju
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Other


External issue ID: 4119

 Description   

Rest Post operation is not working for group function.

when adding new group, Post operation is not working, getting "400" error code.

But Put is working for adding groups to the controller.

i have used to add following group action

{"group": [{"group-name": "TestFlow-0", "buckets": {"bucket": [{"action": [{"order": 0, "pop-vlan-action": {}}], "bucket-id": 0, "watch_group": 0}]}, "group-type": "group-indirect", "group-id": 9, "barrier": "false"}]}



 Comments   
Comment by Dhevendran Kulandaivel [ 18/May/16 ]

(In reply to Anpukarasi Muthukumaran from comment #0)
> Rest Post operation is not working for group function.
>
> when adding new group, Post operation is not working, getting "400" error
> code.
>
> But Put is working for adding groups to the controller.
>
> i have used to add following group action
>
> {"group": [{"group-name": "TestFlow-0", "buckets": {"bucket": [{"action":
> [{"order": 0, "pop-vlan-action": {}}], "bucket-id": 0, "watch_group": 0}]},
> "group-type": "group-indirect", "group-id": 9, "barrier": "false"}]}

Hi Anpukarasi Muthukumaran

Can you provide the steps to reproduce this ?
If you have solid reproduction step, I can take this up

Thanks & Regards,
Dhevendran K

Comment by Abbas P Pareedkunju [ 20/May/16 ]

Hi Anpukarasi,

I would like to have a look in to your issue.
Can you please share the XML file you are trying to use for POST calls, to reproduce this fault?

//Abbas

Comment by Anpukarasi Muthukumaran [ 24/May/16 ]

(In reply to Abbas P Pareedkunju from comment #2)
> Hi Anpukarasi,
>
> I would like to have a look in to your issue.
> Can you please share the XML file you are trying to use for POST calls, to
> reproduce this fault?
>
> //Abbas

Hi Abbas,

I used following json for testing this issue.

{"group": [{"group-name": "TestFlow-0", "buckets": {"bucket": [{"action": [{"order": 0, "pop-vlan-action": {}}], "bucket-id": 0, "watch_group": 0}]}, "group-type": "group-indirect", "group-id": 9, "barrier": "false"}]}

I have raised this issue on almost a year back. Not sure if this issue still there.

Thanks
Anpu

Comment by Abbas P Pareedkunju [ 24/May/16 ]

Thanks for the information. Meantime, I could reproduce the fault with a REST Client, and seeing the same behavior, POST shows "400: Bad Request"
Working on the possibility to fix this.

Comment by Abbas P Pareedkunju [ 25/May/16 ]

Hi Anpu,

I have seen that the ODL code handles the POST operations with an additional check, which causes this problem.
Have sent a email to the Code owner for the suspected area, awaiting his reply to see the feasibility to correct this.

Thanks,
Abbas

Comment by Abbas P Pareedkunju [ 30/May/16 ]

Looking for an a reply on the below queries.

On this issue debug, found that the problem lies in the NodeBodyReader classes (JsonNormalizedNodeBodyReader and XmlNormalizedNodeBodyReader).

When the JsonParserStream object is created in JsonNormalizedNodeBodyReader,
the value for 'parentSchema' passed is "list group" for the POST operation calls
whereas, for PUT operations the value is "list node".

The code to populate 'parentSchema' in JsonNormalizedNodeBodyReader.java has a special check for POST calls as below
If the isPost flag on -> populate parentSchema from getSchemaNode() which returns value of schemaNode
else -> populate from getSchemaContext() which returns value of schemaContext from InstanceIdentifierContext.java

Due to this handling, on POST operations, JsonParserStream.read() will try to resolve namespace by resolveNamespace() which throws IllegalStateException since it is not able to find schema node with type group.

But for PUT operations, resolveNamespace() gets the valid schema name and hence able to proceed.

A similar handling is seen for XML types aswell in XmlNormalizedNodeBodyReader.
Here for both POST and PUT, schemaNode gets a value "list group"
But XmlNormalizedNodeBodyReader has a dedicated check for isPost.
If it is POST, it goes to the method findPathToSchemaNodeByName() where it tries to find the child nodes of schemaNode which would fail.
For PUT, it will never go to this method to check.

Bit confused on why this special check would be required for POST.
Looking for some clarity on this.
Also on if it is OK to use the same XML/JSON for both PUT and POST.

Thanks,
Abbas

Comment by Ivan Hrasko [ 31/May/16 ]

POST is for creating new data and PUT is for creating and updating.

Try to modify your XML/JSON inputs or URIs. Use different inputs for POST and different for PUT.

example (see differences in XML/JSON for POST and PUT):

YANG model: https://github.com/opendaylight/controller/blob/7257dc4ecacf3e4d08273c31accd945fb8f3e769/opendaylight/md-sal/samples/clustering-test-app/model/src/main/yang/car.yang?

PUT:

URI: http://localhost:8181/restconf/config/car:cars

JSON:

{
cars : {
car-entry :

{ id : "0", year : "2000" }

}
}

XML:

<cars xmlns="urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:car">
<car-entry>
<id>0</id>
<year>2000</year>
</car-entry>
</cars>

POST:

URI: http://localhost:8181/restconf/config/car:cars

JSON:

{
car-entry :

{ id: "0", model : "Model", manufacturer : "Manufacturer", year : "2000", category : "Category" }

}

XML:
<car-entry xmlns="urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:car">
<id>0</id>
<model>Model</model>
<manufacturer>Manufacturer</manufacturer>
<year>2000</year>
<category>Category</category>
</car-entry>

Comment by Miroslav Macko [ 23/Aug/16 ]

I have tested it. It works. If there are still issues, please reopen.

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