[NETCONF-719] NETCONF operation failed message - Caused by: org.opendaylight.mdsal.common.api.ReadFailedException: NETCONF operation failed Created: 19/Aug/20  Updated: 30/Sep/20  Resolved: 30/Sep/20

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: Magnesium SR1
Fix Version/s: None

Type: Bug Priority: Medium
Reporter: John Mangan Assignee: Jamo Luhrsen
Resolution: Done Votes: 0
Labels: netconf
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Centos 7 VM

Java11 jre

remotes/origin/stable/magnesium


Attachments: Text File odl-get-mounted-device-config-stack-trace.txt    

 Description   

I have PUT a NETCONF device (Junos vMX r18.2) on ODL (Magnesium stable version) using the following Postman command

PUT http://<MY_CONTROLLER>:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/VMX-1

 
<node xmlns="urn:TBD:params:xml:ns:yang:network-topology"> 
<node-id>VMX-1</node-id> 
<host xmlns="urn:opendaylight:netconf-node-topology"><Device-IP></host> 
<port xmlns="urn:opendaylight:netconf-node-topology">22</port> 
<username xmlns="urn:opendaylight:netconf-node-topology">admin</username> 
<password xmlns="urn:opendaylight:netconf-node-topology">admin</password> 
<tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only> 
<schema-cache-directory xmlns="urn:opendaylight:netconf-node-topology">VMX-2_device_cache</schema-cache-directory> 
<reconnect-on-changed-schema xmlns="urn:opendaylight:netconf-node-topology">true</reconnect-on-changed-schema> 
<connection-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">20000</connection-timeout-millis> 
<default-request-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">60000</default-request-timeout-millis> 
<max-connection-attempts xmlns="urn:opendaylight:netconf-node-topology">0</max-connection-attempts> 
<between-attempts-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">2000</between-attempts-timeout-millis> 
<sleep-factor xmlns="urn:opendaylight:netconf-node-topology">1.5</sleep-factor> 
<keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">120</keepalive-delay> 
</node> 
 
 
 
The device is created ok and I can query the config and operational state
 
GET http://<MY_CONTROLLER>:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/VMX-1/
 
However, when I attempt to retrieve all its capabilities which are available through the mount point using ...
 
http://<MY_CONTROLLER>:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/VMX-1/yang-ext:mount
 
I receive the following reply 
 
{
    "errors": {
        "error": [
            

{                 "error-type": "application",                 "error-tag": "operation-failed",                 "error-message": "NETCONF operation failed"             }

        ]
    }
}
Looking  at the controller log I see exceptions ...
 
Error reading / from datastore CONFIGURATION
java.util.concurrent.ExecutionException: ReadFailedException{message=NETCONF operation failed, errorList=[RpcError [message=NETCONF operation failed, severity=ERROR, errorType=APPLICATION, tag=operation-failed, applicationTag=null, info=null, cause=java.lang.UnsupportedOperationException]]}
at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:553) ~[bundleFile:?]
 
etc 
 
and 
 
Caused by: org.opendaylight.mdsal.common.api.ReadFailedException: NETCONF operation failed
at org.opendaylight.netconf.sal.connect.netconf.sal.tx.ReadOnlyTx$1.onFailure(ReadOnlyTx.java:64) ~[?:?]
at com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1064) ~[bundleFile:?]
 
...
 
 
My controller is installed on Cento7 and build with java11
 
I'm following instructions given in the cookbook
https://subscription.packtpub.com/book/virtualization_and_cloud/9781786462305/1/ch01lvl1sec11/mounting-a-netconf-device
 
 
Is this an issue with what the device is returning ? I can see on the device log its returning the full configuration, but the ODL is failing to read it 
I've tried various release of ODL
 
 
 
 
 
 
 
 
 
 



 Comments   
Comment by John Mangan [ 30/Sep/20 ]

This issue is a consequence of the junos device not revealing its yang schemas during the capabilities exchange. 

This reports can be closed  

Generated at Wed Feb 07 20:15:43 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.