[NETCONF-63] issues mounting device that fails to export some models using get-schema Created: 04/Sep/15  Updated: 15/Mar/19  Resolved: 02/Oct/18

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

Type: Bug
Reporter: Giles Heron Assignee: Giles Heron
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 4257

 Description   

in trying to mount a NETCONF device which supports netconf monitoring but which fails to transfer some of its models on a "get-schema". The device never mounts successfully but becomes stuck "connecting" (the NETCONF connection to the device stays up).

I've tested this on both Lithium and master - and both have the same problem.

zipped logs attached.

 Comments   
Comment by Tomas Cere [ 08/Sep/15 ]

I don't see any logs attached, but in case a device does not provide all of it's models through netconf monitoring you need to sideload them into ODL.

https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Connecting_to_a_device_not_supporting_netconf_monitoring

Since by default there are infinite reconnect attempts unless configured otherwise, the device will stay as connecting.

Comment by Robert Varga [ 13/Nov/15 ]

Move to NETCONFI project.

Comment by Tomas Cere [ 24/Nov/15 ]

Any more info on how the transfer failed? Currently if a model cannot be resolved it will be added into unavailable capabilities as unable to resolve and the connection would continue without it.
If a device is stuck as connecting and not trying to resolve anymore models, and the status doesnt seem to progress we should just fail the connection - this needs to be retested.

Comment by Giles Heron [ 24/Nov/15 ]

I had a device fail earlier because of issues parsing the models, but noticed that ODL still showed the device as "connecting". So that might be the issue.

Comment by Robert Varga [ 27/Aug/18 ]

giheron@cisco.com is this still reproducible?

Comment by Jakub Morvay [ 02/Oct/18 ]

This seems to be really a stale issue. It's couple of releases old and we don't have models and data to replicate this and not even logs we can analyze.

I will close this as cannot reproduce for now. giheron@cisco.com if you can still see the behavior on supported releases, please feel free to reopen the issue.

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