Ask Your Question
0

Error accessing NETCONF device using custom Yang schema

asked 2015-01-14 02:21:59 -0700

updated 2015-03-20 07:12:59 -0700

I am trying to comunicate with a Juniper Device through NETCONF in ODL Helium. I configured the netconf-connector, and obtained a Yang file (which I stored in cache/schema), since the device does not support netconf-monitoring.

I also added

<yang-module-capabilities xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
  <capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
    urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2010-09-24
  </capability>
  <capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
    urn:ietf:params:xml:ns:yang:junos-yang-module-14.2R1.9?module=junos-yang-module-14.2R1.9&revision=2015-01-14
  </capability>

</yang-module-capabilities>

to the netconf-connector definition for the device, to specify the Yang modules.

The device seems to be working, since I see the log message:

2015-01-14 10:03:09,681 | INFO  | ssing-executor-4 | NetconfDevice                    | 376 - org.opendaylight.controller.sal-netconf-connector - 1.1.1.Helium-SR1 | RemoteDevice{sw-opennaas-1}: Netconf connector initialized successfully

But when I try to access the configuration of the device using restconf url: http://localhost:8181/restconf/config/opendaylight-inventory:nodes/opendaylight-inventory:node/sw-opennaas-1/yang-ext:mount/

It gives me an error:

2015-01-14 10:48:30,673 | ERROR | oupCloseable-4-2 | NetconfDeviceReadOnlyTx          | 376 - org.opendaylight.controller.sal-netconf-connector - 1.1.1.Helium-SR1 | RemoteDevice{sw-opennaas-1}: Unable to normalize data for /, data: Node[ImmutableCompositeNode], qName[data], modify[n/a], children.size = 1
java.lang.IllegalArgumentException: Failed to get child operation for Node[ImmutableCompositeNode], qName[data], modify[n/a], children.size = 1
    at org.opendaylight.controller.md.sal.common.impl.util.compat.DataNormalizer.toNormalized(DataNormalizer.java:113)[162:org.opendaylight.controller.sal-common-impl:1.1.1.Helium-SR1]
    at org.opendaylight.controller.sal.connect.netconf.sal.tx.NetconfDeviceReadOnlyTx.transform(NetconfDeviceReadOnlyTx.java:91)[376:org.opendaylight.controller.sal-netconf-connector:1.1.1.Helium-SR1]
    at org.opendaylight.controller.sal.connect.netconf.sal.tx.NetconfDeviceReadOnlyTx.access$100(NetconfDeviceReadOnlyTx.java:41)[376:org.opendaylight.controller.sal-netconf-connector:1.1.1.Helium-SR1]
    at org.opendaylight.controller.sal.connect.netconf.sal.tx.NetconfDeviceReadOnlyTx$1.apply(NetconfDeviceReadOnlyTx.java:68)[376:org.opendaylight.controller.sal-netconf-connector:1.1.1.Helium-SR1]
    at org.opendaylight.controller.sal.connect.netconf.sal.tx.NetconfDeviceReadOnlyTx$1.apply(NetconfDeviceReadOnlyTx.java:60)[376:org.opendaylight.controller.sal-netconf-connector:1.1.1.Helium-SR1]
    at com.google.common.util.concurrent.Futures$1.apply(Futures.java:720)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:859)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:150)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:135)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.Futures$ChainingListenableFuture$1.run(Futures.java:873)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors ...
(more)
edit retag flag offensive close merge delete

Comments

I have the same problem. custom schema. I see the controller reads loads the yang files and I can even list yang files from the device using ietf-netconf-monitoring:get_schema. But on invoking the above restconf I get the same exception as list above. Using Helium SR1.1 Anyone have a clue to the fix ?

msandhu ( 2015-02-09 18:04:32 -0700 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2015-02-11 00:18:39 -0700

Maros gravatar image

updated 2015-02-11 02:49:46 -0700

I have just tested this approach using Helium-SR2 release of ODL with a simulated netconf device (using netconf testtool). Everything worked fine for me. What I did:

1 Started slightly modified netconf testtool (it did not support monitoring and did not provide any schemas, also the get-config operation was hardcoded to return some testing data):

<cont xmlns="urn:opendaylight:test">
    <l>Content</l>
</cont>

2 Put testing yang file in cache/schemas folder (the name of the file has to be test@2014-10-17.yang in this case):

    module test {
    yang-version 1;
    namespace "urn:opendaylight:test";
    prefix "tt";

    revision "2014-10-17";

    container cont {
      leaf l {
        type string;
     }
    }
    }

3 Started ODL 4 Spawned netconf connector that connects to simulated device over restconf. The configuration cotnained this piece of xml:

<yang-module-capabilities xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
    <capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
urn:opendaylight:test?module=test&revision=2014-10-17
    </capability> 
</yang-module-capabilities>

5 Executed over RESTCONF get operation on: http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/newDevice/yang-ext:mount
The data I want were returned.

So could you try with SR2 release ? and also check that your yang schema is correct and the data presented by the device is valid according to that schema ?

If it still does not work for you, I could have a look at your schema and data returned (if possible) or just take a look at the detailed log (with TRACE level set for netconf).

edit flag offensive delete publish link more

Comments

Currently I am suffering from the fact that the Junos <hello> does not include a namespace. While I did manage to establish a netconf connection earlier. See similar issue for Cisco: https://ask.opendaylight.org/question/1532/setting-up-netconf-for-cisco-switch/ . I am hoping to tweak this soon.

ph0tek ( 2015-02-20 04:41:24 -0700 )edit

Maros, I also tried processing our yang files using yang tools for binding aware netconf plugin. The tools could not process all the yang. So I decided use a subset. The yang was validated but the java code generation phase failed. From the logs it looks like a yangtools issue to me. It would be great if you could take a look at the yang files. I can share them with you if you send me your contact.

msandhu ( 2015-03-09 17:57:01 -0700 )edit

Sure, please send the yang models along with the output from the failed build to: mmarsale@cisco.com.

Maros ( 2015-03-13 08:11:37 -0700 )edit

Is without starting controller, is schema can be validated in the netconf session ?? can you please guide me .. I have started the netconf session of the device with the same yang.. I would like to know how to validate the yang in netconf mode ???

bebaskar ( 2015-11-27 04:27:38 -0700 )edit
Login/Signup to Answer

Question Tools

Follow
1 follower

Stats

Asked: 2015-01-14 02:21:59 -0700

Seen: 1,441 times

Last updated: Mar 20 '15