Operating System: Linux
Platform: PC

Can you please provide a karaf.log?

Can you also please provide what error exactly did you get?

Do you really need to call get-config operation explicitly through restconf?
Isn't accessing configuration data through restconf/config sufficient?

(In reply to Jakub Morvay from comment #3)
> Can you also please provide what error exactly did you get?
>
> Do you really need to call get-config operation explicitly through restconf?
> Isn't accessing configuration data through restconf/config sufficient?

<p>Problem accessing /restconf/operations/network-topology:network-topology/topology/topology-netconf/node/turing/yang-ext:mount/ietf-netconf:get-config. Reason:
<pre> Server Error</pre></p><h3>Caused by:</h3><pre>java.lang.IllegalArgumentException: Schema node null does not allow children.
at org.opendaylight.yangtools.yang.data.impl.codec.SchemaTracker.<init>(SchemaTracker.java:86)
at org.opendaylight.yangtools.yang.data.impl.codec.SchemaTracker.create(SchemaTracker.java:125)
at org.opendaylight.yangtools.yang.data.codec.gson.JSONNormalizedNodeStreamWriter.<init>(JSONNormalizedNodeStreamWriter.java:48)
at org.opendaylight.yangtools.yang.data.codec.gson.JSONNormalizedNodeStreamWriter.createNestedWriter(JSONNormalizedNodeStreamWriter.java:184)
at org.opendaylight.controller.sal.rest.impl.NormalizedNodeJsonBodyWriter.createNormalizedNodeWriter(NormalizedNodeJsonBodyWriter.java:139)
at org.opendaylight.controller.sal.rest.impl.NormalizedNodeJsonBodyWriter.writeNormalizedNode(NormalizedNodeJsonBodyWriter.java:100)
at org.opendaylight.controller.sal.rest.impl.NormalizedNodeJsonBodyWriter.writeTo(NormalizedNodeJsonBodyWriter.java:78)
at org.opendaylight.controller.sal.rest.impl.NormalizedNodeJsonBodyWriter.writeTo(NormalizedNodeJsonBodyWriter.java:46)

(In reply to Jakub Morvay from comment #3)
> Can you also please provide what error exactly did you get?
>
> Do you really need to call get-config operation explicitly through restconf?
> Isn't accessing configuration data through restconf/config sufficient?

yes, i need to call get-config operation through restconf to get multiple nodes informaton.

(In reply to moon.lee from comment #5)
> (In reply to Jakub Morvay from comment #3)
> > Can you also please provide what error exactly did you get?
> >
> > Do you really need to call get-config operation explicitly through restconf?
> > Isn't accessing configuration data through restconf/config sufficient?
>
> yes, i need to call get-config operation through restconf to get multiple
> nodes informaton.

Can please explain this multiple nodes information further?

I think POST to
/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/turing/yang-ext:mount/ietf-netconf:get-config
should be conceptually the same thing as GET to
/restconf/config/network-topology:network-topology/topology/topology-netconf/node/turing/yang-ext:mount/

What revision of ietf-netconf module are you using? Why do you think this is caused by revision mismatch?

(In reply to Jakub Morvay from comment #6)
> (In reply to moon.lee from comment #5)
> > (In reply to Jakub Morvay from comment #3)
> > > Can you also please provide what error exactly did you get?
> > >
> > > Do you really need to call get-config operation explicitly through restconf?
> > > Isn't accessing configuration data through restconf/config sufficient?
> >
> > yes, i need to call get-config operation through restconf to get multiple
> > nodes informaton.
>
> Can please explain this multiple nodes information further?
>
> I think POST to
> /restconf/operations/network-topology:network-topology/topology/topology-
> netconf/node/turing/yang-ext:mount/ietf-netconf:get-config
> should be conceptually the same thing as GET to
> /restconf/config/network-topology:network-topology/topology/topology-netconf/
> node/turing/yang-ext:mount/
>
> What revision of ietf-netconf module are you using? Why do you think this is
> caused by revision mismatch?

these two operations are not same. see NETCONF-230.

revision of ietf-netconf in odl is 2011-06-11, in netopeer I use is 2011-03-08

Does netopeer advertise ietf-netconf capability with revision 2011-03-08 in hello message?

(In reply to Jakub Morvay from comment #8)
> Does netopeer advertise ietf-netconf capability with revision 2011-03-08 in
> hello message?

Yes,it advertises.

(In reply to moon.lee from comment #9)
> (In reply to Jakub Morvay from comment #8)
> > Does netopeer advertise ietf-netconf capability with revision 2011-03-08 in
> > hello message?
>
> Yes,it advertises.

In that case, you should be able to call even base netconf operations through restconf, so it looks something is broken.

Can you please provide us karaf.log, so we can have more information, what is really happening.

Attachment karaf.log has been added with description: karaf.log

Hi

by looking at package names in log e.g:

org.opendaylight.controller.sal.rest.impl.NormalizedNodeJsonBodyWriter
you are using pre-Beryllium Restconf which is not supported anymore.
Can you please switch to stable Beryllium first and try again? Many thanks.

Best Regards

Martin

Is this supported in Boron? My apologies, I was on PTO for the call today and may have missed out on the conversation, still reviewing the minutes. It seems like something we ought to support going forward... I don't think that it is particular to pre-Beryllium as I believe this wont work in post-beryllium either...

Right.

We've managed to replicate this bug with latest code base and it seems to be a real issue. Given rpc get-config is not present in rpcs collection, even though ietf-netconf module is part of schema context.
We're currently investigating why this is happening and we'll keep you updated.
Bug reopen, set to critical back again.

Martin

Hi all,

If the device advertises ietf-netconf capability, you are able to call base netconf rpcs via restconf. Tested on master branch, Beryllium should behave in the same way.

Martin replicated this bug on ODL netconf northbound, not on mounted device.
Since this bug is about calling base netconf rpcs on mounted device, I am closing this bug.