Operating System: All
Platform: All

Please provide the details to replicate the bug and the problem being faced .

Thankyou

Please share the process or setup you gone through where in you are facing problem like steps you follow to get depth or nest level.

Thankyou

As per as the http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-3.8.1 link says,

I run my controller from eclipse and produces topology through mininet.I could see the topology on http://localhost:8080/

1.) I tried creating new data resources by POST on RESTclient

POST http://localhost:8080/restconf/config HTTP/1.1
Host: example.com
Content-Type: application/yang.data+json
Body:

but i am getting a error on Restclient as follows :
type Status report
message Not Found
description The requested resource is not available.

2.) Also i tried to add flows through the CLI :

curl -u admin:admin -H 'Content-type: application/json' -X PUT -d '{"installInHw":"true", "name":"flow1", "node":

, "ingressPort":"2", "etherType": "0x800", "protocol": "6", "tpDst": "80", "priority":"65535","actions":["DROP"]}' 'http://localhost:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/staticFlow/flow1'

from which i was able to add flows but when i try see the flows on
http://192.168.1.16:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/1

It gives a reply : No data exists.

3.) I even tried to add flows on the link given:
curl -u admin:admin -H 'Content-type: application/json' -X PUT -d '{"installInHw":"true", "name":"flow1", "node":

, "ingressPort":"2", "etherType": "0x800", "protocol": "6", "tpDst": "80", "priority":"65535","actions":["DROP"]}' 'http://192.168.1.16:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/1'

It gives error not allowing the flows to be added.

I am not able to add new data resource on http://192.168.1.16:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/1 path due to which GET,POST,PUT method is showing error in Restclient.

So please share the steps you follow. Also did adding openflow plugin can help in retrieving the URI??

I am not able to replicate the issue given, so i am assigning the bug back to controller-bugs@lists.opendaylight.org

depth parameter support was added
Change-Id: I44d99f9886e3837a1bb13eda84aec3c4cc6b21ae

Note - looks like the gerrit mentioned was never merged - attempting to follow up and get that functionality merged.

Original commit was still using xtend and was not fully clear. Restconf implementation has changed since then, and maybe this will require additional work.

Looks like this bug as of right now is not assigned out to anyone, so we should assume it is open for work. The code changes in the work item definitely need to be changed and merged with master. That said, there is a clear starting point for who ever wants to take this on.

The definition of depth in Draft 2 of the spec is a little confusing and non-intuitive. It states the

""depth" parameter is used to specify the number of nest levels
returned in a response for a GET method. A nest-level consists of
the target resource and any child nodes which are contained within
the target resource node"

I think people naturally equate depth to tree levels and not nested levels.

It also states:

"the server will include all sub-resources within a
retrieved resource, which have the same resource type as the
requested resource type. Only only level of sub-resources with a
different media type than the target resource will be returned."

I find this a bit confusing even without the grammar error.

Draft 3 re-defines the depth param :

"The "depth" parameter is used to limit the number of levels of sub-
resources that are returned by the server for a GET method request."

So a depth of 1 retrieves just the target resource and no children. This is a way to determine if the resource exists. A depth of 2 retrieves the target resource and just its direct children - a child container would be empty.

Also Draft 3 doesn't put any confusing restrictions on resource type.

I think this is more intuitive so I propose we implement depth as defined in Draft 3.

Patch set 4 under https://git.opendaylight.org/gerrit/#/c/5325/