[NETCONF-1161] Callhome Issues with ODL Netconf and Callhome Codebase Created: 20/Sep/23 Updated: 18/Oct/23 |
|
| Status: | Open |
| Project: | netconf |
| Component/s: | netconf, netconf-topology |
| Affects Version/s: | 2.0.17, 3.0.9, 4.0.5, 5.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | High | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Reporter: | Samit Ghosh | Assignee: | Ivan Hrasko | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Resolution: | Unresolved | Votes: | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Labels: | netconf | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Remaining Estimate: | Not Specified | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Time Spent: | Not Specified | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Original Estimate: | Not Specified | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Environment: |
214 | 1.3.0 | org.onap.ccsdk.features.sdnr.wt.sdnr-wt-devicemanager-o-ran-sc-oran-provider | active |
```
| ConnectApp | 142.63ceae1(22/01/31)|
| NetworkMapApp | |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Attachments: |
karaf-callhome-device-debug.log
karaf-normal-device-debug.log
|
||||||||
| Issue Links: |
|
||||||||
| Priority: | High | ||||||||
| Description |
| Comments |
| Comment by Samit Ghosh [ 05/Oct/23 ] |
|
Adding the version information of the various components that we seeking a solution for: |
| Comment by Ivan Hrasko [ 16/Oct/23 ] |
|
Observation #1 What is the issue, here? I have successfully connected a call home device using steps you have provided: # Configure ODL to accept all ssh keys from Callhome Clients
curl -v -u admin:Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U -X PUT http://192.168.101.242:30181/rests/data/odl-netconf-callhome-server:netconf-callhome-server/global -H "accept: */*" -H 'content-type: application/json' -d '{ "global": {"accept-all-ssh-keys": "true" } }'
# Configure ODL to accept Callhome devices with credentials
# user/pwd --> netconf/netconf
curl -v -u admin:Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U -X PUT "http://192.168.101.242:30181/rests/data/odl-netconf-callhome-server:netconf-callhome-server/global/credentials" -H "accept: */*" -H "Content-Type:application/json" -d "{\"credentials\":{\"username\":\"netconf\",\"passwords\":[\"netconf\"]}}"
After issuing GET http://localhost:8181/rests/data/network-topology:network-topology/topology=topology-netconf?content=all {
"network-topology:topology": [
{
"topology-id": "topology-netconf",
"node": [
{
"node-id": "172.17.0.2:55998",
"netconf-node-topology:connection-status": "connected",
"netconf-node-topology:port": 55998,
"netconf-node-topology:available-capabilities": {
"available-capability": [
{
"capability": "urn:ietf:params:netconf:capability:notification:1.0",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:confirmed-commit:1.1",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all,report-all-tagged,trim,explicit",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:candidate:1.0",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:base:1.0",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:validate:1.1",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:startup:1.0",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&content-id=1",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:base:1.1",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:rollback-on-error:1.0",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:interleave:1.0",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:writable-running:1.0",
"capability-origin": "device-advertised"
},
{
"capability": "urn:ietf:params:netconf:capability:xpath:1.0",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount?revision=2019-01-14)ietf-yang-schema-mount"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-datastores?revision=2018-02-14)ietf-datastores"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-netconf-server?revision=2019-07-02)ietf-netconf-server"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-tls-server?revision=2019-07-02)ietf-tls-server"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-restconf?revision=2017-01-26)ietf-restconf"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-tcp-server?revision=2019-07-02)ietf-tcp-server"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-keystore?revision=2019-07-02)ietf-keystore"
},
{
"capability": "(http://www.sysrepo.org/yang/sysrepo?revision=2021-10-08)sysrepo"
},
{
"capability": "(urn:ietf:params:xml:ns:netconf:notification:1.0?revision=2008-07-14)notifications",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-netconf-nmda?revision=2019-01-07)ietf-netconf-nmda"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications?revision=2019-09-09)ietf-subscribed-notifications"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-ssh-server?revision=2019-07-02)ietf-ssh-server"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-ssh-common?revision=2019-07-02)ietf-ssh-common"
},
{
"capability": "(urn:sysrepo:plugind?revision=2022-08-26)sysrepo-plugind",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-inet-types?revision=2013-07-15)ietf-inet-types",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?revision=2012-02-06)ietf-netconf-notifications",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-ip?revision=2018-02-22)ietf-ip"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name?revision=2014-12-10)ietf-x509-cert-to-name",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-yang-library?revision=2019-01-04)ietf-yang-library"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?revision=2011-06-01)ietf-netconf-with-defaults",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-yang-patch?revision=2017-02-22)ietf-yang-patch"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-yang-push?revision=2019-09-09)ietf-yang-push"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-origin?revision=2018-02-14)ietf-origin"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-tls-common?revision=2019-07-02)ietf-tls-common"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-yang-structure-ext?revision=2020-06-17)ietf-yang-structure-ext"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?revision=2010-10-04)ietf-netconf-monitoring",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-crypto-types?revision=2019-07-02)ietf-crypto-types"
},
{
"capability": "(http://www.sysrepo.org/yang/sysrepo-monitoring?revision=2022-08-19)sysrepo-monitoring"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-tcp-common?revision=2019-07-02)ietf-tcp-common"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-yang-types?revision=2013-07-15)ietf-yang-types",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-truststore?revision=2019-07-02)ietf-truststore"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:iana-crypt-hash?revision=2014-08-06)iana-crypt-hash",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-yang-metadata?revision=2016-08-05)ietf-yang-metadata",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:netmod:notification?revision=2008-07-14)nc-notifications",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-netconf-acm?revision=2018-02-14)ietf-netconf-acm",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-tcp-client?revision=2019-07-02)ietf-tcp-client"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-network-instance?revision=2019-01-21)ietf-network-instance"
},
{
"capability": "(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2013-09-29)ietf-netconf",
"capability-origin": "device-advertised"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:ietf-interfaces?revision=2018-02-20)ietf-interfaces"
},
{
"capability": "(urn:ietf:params:xml:ns:yang:1?revision=2022-06-16)yang",
"capability-origin": "device-advertised"
}
]
},
"netconf-node-topology:host": "172.17.0.2"
}
]
}
]
}
You can verify the call home device status at http://localhost:8181/rests/data/odl-netconf-callhome-server:netconf-callhome-server {
"odl-netconf-callhome-server:netconf-callhome-server": {
"global": {
"accept-all-ssh-keys": true,
"credentials": {
"username": "netconf",
"passwords": [
"netconf"
]
}
},
"allowed-devices": {
"device": [
{
"unique-id": "172.17.0.2:55998",
"ssh-client-params": {
"host-key": "AAAAB3NzaC1yc2EAAAADAQABAAABAQCwqz0kHv7iZdXSqYSaYTyvdtTayJ8Yqu3BhqLWQupsURWnkSJx8XUsUtwSOvTiEiNPCL8UOQaaWL3OLOyKqldCP9uZfSTd/47O27s7OTm10bKsLT3mTk21+bzLslPgWntxrFTZJzpG0HIjUf0WNYZwIE3HY8bZAYddDi38kS20oRrBjdWbC0XUxmyCVDh8oucegOLhHj12w9a5iBSEKosx0T63maIVr8M0IU7HnaQ1sp9/OBJmygI5r+EFWh7ao279W9v/pH5mMSHZnYIFthWpzpO0JMoksSXIktNBFkfAVjZr/+NvNj7tq8Xd6lILHrWBdeqY3kjTH7BiMoNjLa0N"
},
"callhome-status:device-status": "CONNECTED"
}
]
}
}
}
It's CONNECTED. You are complaining about: org.onap.ccsdk.features.sdnr.wt.sdnr-wt-devicemanager-core-provider - 1.3.0 | - | mount-method: null (null) But this part is out of control of ODL. In addition, your "Opendaylight karaf.log (logs of relevance for the callhome device) " shows that device is not connected, its: "status":"Connecting". Can you please just provide steps to reproduce issue with ODL? What is the expected behavior? |
| Comment by Ivan Hrasko [ 16/Oct/23 ] |
|
Observation #2 You need to realize that call-home devices are not written by user into configuration data-store. It means that when you run: The configuration for call-home devices is written into: http://localhost:8181/rests.data/odl-netconf-callhome-server:netconf-callhome-server/allowed-devices http://localhost:8181/rests/data/odl-netconf-callhome-server:netconf-callhome-server/global/credentials You have described an issue that you have written device data into netconf-topology (configuration) directly and you have wondered why when deleted the desired (which one?) call-home device has not been deleted. That's because this configuration is not a call-home device nor its connected with any existing call-home devices. |
| Comment by Ivan Hrasko [ 16/Oct/23 ] |
|
IMHO this seems like no issue on ODL side. Its rather misunderstanding of the call-home feature and/or possible issues in ONAP/your ODL GUI, etc. |
| Comment by Samit Ghosh [ 17/Oct/23 ] |
|
Thanks for looking into this matter. In my analysis of the problem, I was trying to compare a normal device with a call-home device and trying to understand the differences and the problem. What you're saying is that the call home device needs to be referenced from an in-memory store rather than the persistent datastore? Is that what you're trying to say with the http://localhost:8181/rests/data/odl-netconf-callhome-server:netconf-callhome-server path? Does this mean that the capabilities of the call home device are not known to the controller? How does one reference the capabilities of the call home device and how does one delete such a device. Can you please provide examples of the same using the northbound? |
| Comment by Ivan Hrasko [ 17/Oct/23 ] |
|
AFAICT there is no way to delete call-home device. There is no implementation for this. |
| Comment by Samit Ghosh [ 17/Oct/23 ] |
|
Can this be functionality that can be built into ODL? |
| Comment by Ivan Hrasko [ 18/Oct/23 ] |
|
IMO yes, that functionality would be a resolution for NETCONF-989. |