search

openconfig / public

Repository for publishing OpenConfig models, documentation, and other material for the community.
Apache License 2.0
875 stars 643 forks source link

Using Opendaylight to connect to an Openconfig supported device #191

Open rdpravin1895 opened 5 years ago

rdpravin1895 commented 5 years ago

I am trying to connect to a openconfig supported netconf device using Opendaylight (ODL). The device does not support netconf-monitoring. Hence, I have placed the yangs in the schema folder manually.

The issue is, ODL is not able to resolve few yangs. They are:

The above yangs have augments to other yangs that have been resolved in ODL. When I try to do a get or get-config on the resolved yang's api, since the yangs have data augmented from the unresolved yangs, ODL is not able to parse the received netconf message with the data.

I have even posted the same question in ODL mailing list and waiting for their reply. Has anyone successfully connected to an Openconfig device using ODL?

aashaikh commented 5 years ago

When you say ODL can't resolve these modules, can you please specify the error you are seeing? Is it a YANG tools error from the ODL YANG parser/compiler?

rdpravin1895 commented 5 years ago

No. I am able to compile the yangs successfully. But for my requirement the compilation of yangs is not needed.

I have placed the yangs in the schema folder since the device does not support netconf monitoring. After doing this few of the yangs are getting resolved (ie) ODL is able to recognize those yangs and expose the mount api's.

When I try to do a get-config on openconfig-platform yang - components container, I am receiving the data from the device which I verified by looking in to the ODL logs. But ODL is not able to parse and store the data in its database, since the received data contains augments from yangs that are not resolved. The reason why they are not getting resolved is not being shown in the logs. Below is the error I am getting:

2018-11-01 07:17:28,720 | DEBUG | tform:components | estconfDocumentedExceptionMapper | 323 - org.opendaylight.netconf.sal-rest-connector - 1.6.3 | In toResponse: errors: [RestconfError [error-type: application, error-tag: operation-failed, error-message: read execution failed, error-info: java.lang.IllegalArgumentException: Failed to parse data response [data: null] at org.opendaylight.netconf.sal.connect.netconf.schema.mapping.NetconfMessageTransformer.toRpcResult(NetconfMessageTransformer.java:199) at org.opendaylight.netconf.sal.connect.netconf.schema.mapping.NetconfMessageTransformer.toRpcResult(NetconfMessageTransformer.java:58) at org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceRpc.lambda$invokeRpc$1(NetconfDeviceRpc.java:70) at com.google.common.util.concurrent.AbstractTransformFuture$TransformFuture.doTransform(AbstractTransformFuture.java:239) at com.google.common.util.concurrent.AbstractTransformFuture$TransformFuture.doTransform(AbstractTransformFuture.java:229) at com.google.common.util.concurrent.AbstractTransformFuture.run(AbstractTransformFuture.java:130) at com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:399) at com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911) at com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:822) at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:664) at org.opendaylight.netconf.sal.connect.netconf.listener.UncancellableFuture.set(UncancellableFuture.java:44) at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.processMessage(NetconfDeviceCommunicator.java:349) at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onMessage(NetconfDeviceCommunicator.java:278) at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onMessage(NetconfDeviceCommunicator.java:48) at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handleMessage(AbstractNetconfSession.java:72) at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handleMessage(AbstractNetconfSession.java:38) at org.opendaylight.protocol.framework.AbstractProtocolSession.channelRead0(AbstractProtocolSession.java:53) at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:341) at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:341) at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293) at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:280) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:396) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:38) at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:354) at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:403) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:445) at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858) at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.IllegalStateException: Schema for node with name optical-port and namespace http://openconfig.net/yang/transport-line-common does not exist at AbsoluteSchemaPath{path=[(http://openconfig.net/yang/platform?revision=2018-01-30)components, (http://openconfig.net/yang/platform?revision=2018-01-30)component]} at com.google.common.base.Preconditions.checkState(Preconditions.java:750) at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:366) at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:297) at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:373) at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:373) at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.parse(XmlParserStream.java:191) at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.traverse(XmlParserStream.java:220) at org.opendaylight.netconf.sal.connect.netconf.schema.mapping.NetconfMessageTransformer.toRpcResult(NetconfMessageTransformer.java:196) ... 38 more

aashaikh commented 5 years ago

I'm not sure how to address this if we don't know why the ODL compiler can't resolve some of the dependencies. Are you specifying the full set of schema modules for the platform components model? Each type of component has its own yang module defined.

What is the target device you are working with? Is it possible it is using some platform-specific augments (i.e., non OpenConfig modules)?

einarnn commented 5 years ago

@rdpravin1895, it would also help if you included details of the data returned by the device that ODL is failing to parse.

As an aside, in the past I have found ODL to be very “unforgiving”, and in this case if the data is “unresolved” (e.g. comes from an augmentation ODL doesn’t know about, which is possible with Netconf if ODL hasn’t discovered the schema from the device), then ODL unnecessarily (IMO) throws exceptions. It should probably log “unrecognized” content, but not error out.

rdpravin1895 commented 5 years ago

I'm not sure how to address this if we don't know why the ODL compiler can't resolve some of the dependencies. Are you specifying the full set of schema modules for the platform components model? Each type of component has its own yang module defined.

What is the target device you are working with? Is it possible it is using some platform-specific augments (i.e., non OpenConfig modules)?

Yes it is using augments from vendor specific models which I cannot share here. But that is not the issue as those models are getting resolved. ODL is not able to resolve the 3 yangs that I have specified in my first message. That means, it is not able to validate those yangs and hence when I do a get operation on the device for openconfig-platform yang, even though I am able to receive the Netconf XML data, it is not getting mapped to the Yang model so that the data can be stored in the database.

I am digging through the ODL logs to find the reason why the yangs are not getting resolved. Will update once I find it.

The Netconf device is a third-party vendor's device - Nokia 1830 switch. I cannot share any more details of it.

rdpravin1895 commented 5 years ago

@rdpravin1895, it would also help if you included details of the data returned by the device that ODL is failing to parse.

ENABLED @einarnn This is a small part of the data that is failing to parse. This is being augmented from the transport-line-common yang, which is not getting resolved. > > As an aside, in the past I have found ODL to be very “unforgiving”, and in this case if the data is “unresolved” (e.g. comes from an augmentation ODL doesn’t know about, which is possible with Netconf if ODL hasn’t discovered the schema from the device), then ODL unnecessarily (IMO) throws exceptions. It should probably log “unrecognized” content, but not error out. The device I am using does not have monitoring capability. Hence I have to place the yangs in the schema folder of ODL manually so that ODL can resolve the schema when any netconf operations are made on the device. But the device is getting discovered as the device's connection status is connected in the topology data of ODL and the mount for the device is also created. The reason for parse error is, the schema for the 3 yangs that I have mentioned above is not getting resolved. Hence when data mapping is happening after the xml data is received, ODL is not able to find the corresponding objects for certain fields. These fields are augmented to platform yang from the 3 unresolved yangs.
kmckeown1890 commented 2 years ago

I have a similar issue, did you ever figure out how to resolved the schema parsing if they are added manually to the schema folder

Nshet commented 2 years ago

I do have same issue with openconfig-platform-psu.yang state attributes like enabled,input-current,input-voltage and other. could you please let us know what we can do to parse the xml successfully?

github-actions[bot] commented 2 weeks ago

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.