https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-723 yangtools <p>when mounting some types of device I'm seeing the mount fail with "No more sources for schema context'.</p> <p>I see this in the logs:</p> <p>2016-11-29 17:39:00,580 | DEBUG | ssing-executor-9 | NetconfDevice | 315 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR1 | RemoteDevice</p> {3850}: Unable to map any source identifiers to a capability reported by device : []<br/> 2016-11-29 17:39:00,580 | WARN | ssing-executor-9 | NetconfDevice | 315 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR1 | RemoteDevice{3850} <p>: Unable to build schema context, unsatisfied imports {}, will reattempt with resolved only<br/> 2016-11-29 17:39:00,581 | DEBUG | ssing-executor-9 | NetconfDevice | 315 - org.opendaylight.netconf.sal-netconf-connector - 1.4.1.Boron-SR1 | {}: Unable to build schema context, unsatisfied imports {}, will reattempt with resolved only<br/> SchemaResolutionException{unsatisfiedImports={}}<br/> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)<span class="error">&#91;:1.8.0_111&#93;</span><br/> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)<span class="error">&#91;:1.8.0_111&#93;</span><br/> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)<span class="error">&#91;:1.8.0_111&#93;</span><br/> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)<span class="error">&#91;:1.8.0_111&#93;</span><br/> at org.opendaylight.yangtools.util.concurrent.ReflectiveExceptionMapper.newWithCause(ReflectiveExceptionMapper.java:31)<span class="error">&#91;47:org.opendaylight.yangtools.util:1.0.1.Boron-SR1&#93;</span><br/> at org.opendaylight.yangtools.util.concurrent.ExceptionMapper.apply(ExceptionMapper.java:87)<span class="error">&#91;47:org.opendaylight.yangtools.util:1.0.1.Boron-SR1&#93;</span><br/> at org.opendaylight.yangtools.util.concurrent.ExceptionMapper.apply(ExceptionMapper.java:37)<span class="error">&#91;47:org.opendaylight.yangtools.util:1.0.1.Boron-SR1&#93;</span><br/> at com.google.common.util.concurrent.Futures$MappingCheckedFuture.mapException(Futures.java:1809)<span class="error">&#91;44:com.google.guava:18.0.0&#93;</span><br/> at com.google.common.util.concurrent.AbstractCheckedFuture.checkedGet(AbstractCheckedFuture.java:85)<span class="error">&#91;44:com.google.guava:18.0.0&#93;</span><br/> at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$SchemaSetup.setUpSchema(NetconfDevice.java:452)<span class="error">&#91;315:org.opendaylight.netconf.sal-netconf-connector:1.4.1.Boron-SR1&#93;</span><br/> at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$SchemaSetup.run(NetconfDevice.java:428)<span class="error">&#91;315:org.opendaylight.netconf.sal-netconf-connector:1.4.1.Boron-SR1&#93;</span><br/> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)<span class="error">&#91;:1.8.0_111&#93;</span><br/> at java.util.concurrent.FutureTask.run(FutureTask.java:266)<span class="error">&#91;:1.8.0_111&#93;</span><br/> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)<span class="error">&#91;:1.8.0_111&#93;</span><br/> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)<span class="error">&#91;:1.8.0_111&#93;</span><br/> at java.lang.Thread.run(Thread.java:745)<span class="error">&#91;:1.8.0_111&#93;</span><br/> Caused by: java.lang.NullPointerException</p> <p>So it seems that ODL thinks it has unsatisfied imports, but that the list of such imports is empty.</p> <p>any idea what's going on here?</p> <p>Operating System: Linux<br/> Platform: PC</p> YANGTOOLS-723

ODL fails to mount device - shows empty list of unsatisfied imports

Bug Resolved Done Robert Varga Giles Heron Tue, 29 Nov 2016 20:50:41 +0000 Sun, 10 Apr 2022 18:35:56 +0000 Wed, 8 Mar 2017 18:09:17 +0000 0 5 <p>I checked, and I see the same behaviour with Beryllium-SR4 but Lithium-SR4 works ok. So I guess this is something to do with the stricter YANG checking in Beryllium?</p> <p>The full stack trace would be nice since it's cut off at the interesting part and you cant see the cause of the NPE.</p> <p>I've deleted most of the log to leave the stuff potentially relevant to the error.</p> <p>Attachment karaf.log has been added with description: last couple of hundred lines of the log</p> <p>Hi Giles,</p> <p>I've looked at the log and this behavior is indeed strange. Can you please also provide yang models, so I can reproduce this?</p> <p>will mail you a zip of the YANG models (comes to 1.4MB even as a ZIP so can't send it here).</p> <p>This part has been omitted from original report:</p> <p>Caused by: java.lang.NullPointerException<br/> at org.opendaylight.yangtools.yang.common.QName.create(QName.java:211)<br/> at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.TypeUtils.typeEffectiveSchemaPath(TypeUtils.java:209)<br/> at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.effective.type.UnsignedIntegerTypeEffectiveStatementImpl.&lt;init&gt;(UnsignedIntegerTypeEffectiveStatementImpl.java:33)<br/> at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.TypeStatementImpl$Definition.createEffective(TypeStatementImpl.java:188)<br/> at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.TypeStatementImpl$Definition.createEffective(TypeStatementImpl.java:82)<br/> at org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementContextBase.buildEffective(StatementContextBase.java:445</p> <p>NPE is caused by QName.create() being called with a null base, which in turn points to TypeUtils doing:</p> <p> final SchemaPath path = stmtCtx.getSchemaPath().get();<br/> final QName qname = stmtCtx.getFromNamespace(QNameCacheNamespace.class,<br/> QName.create(path.getParent().getLastComponent()</p> <p>In this path.getParent() is YangInstanceIdentifier.EMPTY, which is the only case where getLastComponent() returns null.</p> <p>The stack classes involved are pointing at an uint typedef or leaf. Models need to be analyzed.</p> <p>boron: <a href="https://git.opendaylight.org/gerrit/49143" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/49143</a></p> <p>will report more information so we can track it down.</p> <p>Thinking about this a bit more, the probable cause for this is a free-standing 'type' statement &#8211; which would constitute invalid yang.</p> <p>(In reply to Giles Heron from comment #5)<br/> &gt; will mail you a zip of the YANG models (comes to 1.4MB even as a ZIP so<br/> &gt; can't send it here).</p> <p>Hi Giles, send the models to Peter Kajsa or Igor Foltin (Yang team). Thanks.</p> <p>will do once I have the models. For this one I need access to a real cisco switch that has the issue (7267 doesn't occur with CSR1Kv but only with a real switch). Kevin/Jason have the switches so I need to get hold of them once they're in today.</p> <p>Furthermore, this is a side-effect of when and how we validate sub-statements &#8211; which happens only after the parent has been fully declared.</p> <p>Hence I can do</p> <p>container foo {<br/> type uint8;<br/> }</p> <p>and while it will blow up, it will do so very late in processing, at which point someone may have asked for the effective statement.</p> <p>That leads to TypeEffectiveStatementImpl being invoked in a context, which the implementation does not expect (hey, 'type' can occur only nested in a different statement, hence it's parent path is non-empty... kaboom).</p> <p>BUG-7037 tracks an improvement to lookups, which means that the fact that 'type' statement has no place under container the very first time we attempt to start to define it, throwing a SourceException pinpointing the offender &#8211; allowing NETCONF to properly exclude it (and hence fix this particular issue).</p> <p>Workaround patch for parser to add the offender identification &#8211; that should be sufficient for NETCONF to prune the offender. The root cause needs to be still investigated.</p> <p>master: <a href="https://git.opendaylight.org/gerrit/49351" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/49351</a></p> <p>boron: <a href="https://git.opendaylight.org/gerrit/49433" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/49433</a></p> <p>Hi Giles, I tested the models you provided and the only problem came up with the model ned-switching-devs@2016-04-20.</p> <p>deviation /ned:native/ned:class-map/ned:match/ned:access-group/ned:index {<br/> deviate replace {<br/> type uint32 </p> { range "1..2799"; tailf:info "&lt;1-2799&gt;;;Access list index"; } <p> }<br/> }</p> <p>The issue was that the type uint32 statement had an empty parent.<br/> It is a problem in yang parser code, so I will open a new bug for that.</p> <p>Attachment short.log has been added with description: ODL log (starting with the instance data)</p> <p>Attachment openconfig-interfaces@2015-11-20.yang has been added with description: YANG model with missing instance data</p> Development External issue ID 7267 External issue URL Issue Type ODL SR Target Milestone Rank 0|i028zj: