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-590 yangtools <p>The module exists on the netconf node and the yang file for that is successfully parsed and seen as available capabilities in netconf operational tree</p> <p>HTTP ERROR 500</p> <p>Problem accessing /restconf/config/network-topology:network-topology/topology/topology-netconf/node/vyatta-4.1/yang-ext:mount/vyatta-security-v1:security/. Reason:</p> <p> Server Error</p> <p>Caused by:</p> <p>java.lang.RuntimeException: RemoteDevice</p> {vyatta-4.1} <p>: readOperationalData failed<br/> at org.opendaylight.netconf.sal.connect.netconf.sal.tx.ReadOnlyTx.readWithTimeout(ReadOnlyTx.java:170)<br/> at org.opendaylight.netconf.sal.connect.netconf.sal.tx.ReadOnlyTx.readConfigurationData(ReadOnlyTx.java:87)<br/> at org.opendaylight.netconf.sal.connect.netconf.sal.tx.ReadOnlyTx.read(ReadOnlyTx.java:139)<br/> at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.readDataViaTransaction(BrokerFacade.java:194)<br/> at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.readConfigurationData(BrokerFacade.java:87)<br/> at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.readConfigurationData(RestconfImpl.java:663)<br/> at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.readConfigurationData(StatisticsRestconfServiceWrapper.java:95)<br/> at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.readConfigurationData(RestconfCompositeWrapper.java:72)<br/> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br/> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br/> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br/> at java.lang.reflect.Method.invoke(Method.java:606)<br/> at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)<br/> at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)<br/> at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)<br/> at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)<br/> at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)<br/> at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)<br/> at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)<br/> at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)<br/> at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)<br/> at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)<br/> at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)<br/> at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)<br/> at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)<br/> at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)<br/> at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)<br/> at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)</p> <p>Operating System: All<br/> Platform: All</p> YANGTOOLS-590

java.lang.RuntimeException: RemoteDevice{}: readOperationalData failed

Bug Resolved Done Peter Kajsa Carol Sanders Wed, 9 Mar 2016 18:33:04 +0000 Sun, 10 Apr 2022 18:35:45 +0000 Thu, 12 May 2016 21:51:46 +0000 0 8 <p>Additionally,<br/> This device and version work in Li.</p> <p>Hi Carol,</p> <p>This server response with exception doesn't contain enough information to find the problem causing this error.</p> <p>If it is possible and this stuff isn't confidential, can you also attach karaf log, device configuration and relevant yang schemas?</p> <p>Or at least karaf's ERROR log related to this data read would be helpful.</p> <p>Attachment karaf.zip has been added with description: karaf.log</p> <p>I checked provided log and it seems that this issue is not netconf related. </p> <p>Log:<br/> 2016-03-08 22:58:33,901 | WARN | ssing-executor-9 | NetconfDevice | 228 - org.opendaylight.netconf.sal-netconf-connector - 1.3.0.Beryllium-RC2 | RemoteDevice</p> {vyatta-4.1} <p>: Unable to build schema context, unsatisfied imports </p> {SourceIdentifier [name=ietf-netconf-monitoring@2010-10-04]=[ModuleImportImpl [name=ietf-inet-types, revision=2010-09-24], ModuleImportImpl [name=ietf-yang-types, revision=2010-09-24]], SourceIdentifier [name=vyatta-interfaces-l2tpeth-v1@2015-08-14]=[ModuleImportImpl [name=vyatta-xconnect-v1, revision=null]]} <p>, will reattempt with resolved only</p> <p>indicates that some modules are missing from device's schema context. Read error states that you want to read unknown nodes data (node firewall in container security). Is this node defined in vyatta-interfaces-l2tpeth-v1 module or its submodules?</p> <p>Yes this module is defined. In addition we tested the same node on Lithium and it works fine. On Be, yang modules are resolved and shown in available capabilities in the operational store. However when we do a get on that, controller is unable to parse even though it's in resolved state. This looks like a regression from Li to Be.</p> <p>I think we know the cause. One of the YANG files has pattern restrictions for the value.</p> <p>If you see the pattern values are not enclosed in double quotes. When I enclose them in double quotes, we do not see the problem. But we see the issue when they are not. However on Li this is not an issue. Is this something changed in Be? Is the validation more strict in Be?</p> <p>Also refer to this bug which is also related to patterns. ( Go to the end of comments section)</p> <p><a href="https://bugs.opendaylight.org/show_bug.cgi?id=5396" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=5396</a></p> <p> leaf vhost {<br/> configd:help "Virtio vhost devices";<br/> type union {<br/> type types:interface-ifname </p> { pattern dp[0-9]+vhost[0-9]+; } <p> type types:interface-ifname </p> { pattern dp[0-9]+vhost[0-9]+\.[1-9][0-9]*; } <p> }<br/> }</p> <p>The new yang statement parser has been introduced in Beryllium release of Yang Tools. Pattern value should be enclosed in double quotes, since it may contains characters like ';','</p> {','} <p>' etc.</p> <p>But the quotes are not mandatory if no escaping is required right. By making this mandatory we are artificially making it a requirement and hence are breaking files which may not have it. I don't think YANG specifications require quotes for patterns unless it needs escaping.</p> <p>If an expression contains one of the following characters ('\r' | '\n' | '\t' | ' ' | ';' | '</p> {' | '"' | '\'' | '/' | '=' | '[' | ']' | '+' | '} <p>'), it must be enclosed in "" or ''.</p> <p>Peter, Can you please take a look at this?<br/> <a href="https://bugs.opendaylight.org/show_bug.cgi?id=5396" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=5396</a></p> <p>Regex processing seems to have broken in Be.</p> <p>STRING definition in old parser (used in Lithium):</p> <p>STRING: ((_{( '\r' | '\n' | '\t' | ' ' | ';' | '{' | '"' | '\'')}( '\r' | '\n' | '\t' | ' ' | ';' | '{' )* ) | SUB_STRING ) -&gt;popMode;</p> <p>STRING definition in new parser:</p> <p>STRING : ((~( '\r' | '\n' | '\t' | ' ' | ';' | '</p> {' | '"' | '\'' | '/' | '=' | '[' | ']' | '+' | '} <p>' )~( '\r' | '\n' |<br/> '\t' | ' ' | ';' | '</p> {' | '/' | '=' | '[' | ']' | '} <p>')* ) | SUB_STRING );</p> <p>Which adds additional characters such as =[]} to exclusion which does not seems correct.</p> <p>Hmmm ok, I will discuss this issue with author of the grammar, maybe he had some reasons for this change (e.g. fix of a bug etc.).</p> <p>Any progress here?</p> <p>We are trying to change current yang statement grammar to support such arguments and retest all yang models. Still in progress.</p> <p>Yang lexer fix: <a href="https://git.opendaylight.org/gerrit/#/c/38190/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/38190/</a><br/> Please retest with this patch.</p> <p>be: <a href="https://git.opendaylight.org/gerrit/#/c/38219/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/38219/</a></p> Blocks YANGTOOLS-586 Duplicate YANGTOOLS-605 Development External issue ID 5484 External issue URL Issue Type ODL SR Target Milestone Rank 0|i0285z: