[NETCONF-734] The submodule rpc is not working as expected. Created: 13/Oct/20  Updated: 01/Feb/22  Resolved: 01/Feb/22

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

Type: Bug Priority: Medium
Reporter: Wanxin Cai Assignee: Ivan Martiniak
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Microsoft Word [NETCONF-734] Steps to reproduce.rtf     File bytedance-dns-rpc.yang     File bytedance-dns.yang     Text File karaf.log    
Issue Links:
Issue split
split to NETCONF-856 Integrate message-id and other NETCON... Confirmed

 Description   

I've trying to implement rpc statement in submodule and included from module for separation of concerns purpose, and both "sysrepo" and "pyang" are able to interpret it correctly, which is directly bind the rpc statement under the main module.

 

However, when the data comes to ODL it triggers the following error:

2020-10-12T19:45:36,116 | INFO | nioEventLoopGroupCloseable-3-1 | StreamWriterFacade | 317 - org.opendaylight.yangtools.yang-data-codec-xml - 4.0.13 | Encountered annotation message-id not bound to module. Please examine the call stack and fix this warning by defining a proper YANG annotation to cover it

2020-10-12T19:45:36,525 | WARN  | remote-connector-processing-executor-11 | NetconfDevice                    | 287 - org.opendaylight.netconf.sal-netconf-connector - 1.11.2 | RemoteDevice{ark85}: Unable to build schema context, unsatisfied imports {RevisionSourceIdentifier [name=bytedance-dns@2020-10-13]=[ModuleImportImpl [name=bytedance-dns-rpc, revision=null, semanticVersion=null]]}, will reattempt with resolved only

from my perspective, the message-id is referring to the message-id for rpc message, that is to say it's failed to be bound to the main module for some reason, I'm wondering if there's any way to solve this issue?

The attachment is the yang model corresponding to this issue.

The Yang Tool Version that I use is 4.0.13.

 Comments   
Comment by Robert Varga [ 18/Oct/20 ]

So this is a module and a submodule, and yes, it would seem that 'bytedance-dns-rpc' is missing. This is not a general yangtools issue, as it can properly resolve the two if they are being fed into it.

I suspect this is either a problem with the device (i.e. announced sources, etc.) or NETCONF.

Comment by Robert Varga [ 18/Oct/20 ]

libraskywalker can you post some information about the SB device you are connecting to?

Comment by Robert Varga [ 18/Oct/20 ]

Specifically I think we need:

  • netconf capabilities it reports
  • the content of ietf-netconf-monitoring (if implemented)
  • yang-library content (if implemented)

 

Comment by BoZhang [ 16/Dec/20 ]

encounter same problem I think,  I'm trying to integrating FRR which also use submodule and include in it's frr-bgp.yang, same error was triggered as below:

 

2020-12-15T20:04:14,878 | WARN  | remote-connector-processing-executor-11 | NetconfDevice                    | 287 - org.opendaylight.netconf.sal-netconf-connector - 1.11.2 | RemoteDevice{ark102}: Netconf device provides additional yang models not reported in hello message capabilities: [(http://frrouting.org/yang/route-types?revision=2018-03-28)frr-route-types, (urn:ietf:params:xml:ns:yang:ietf-yang-library?revision=2019-01-04)ietf-yang-library, (urn:ietf:params:xml:ns:yang:ietf-crypto-types?revision=2019-07-02)ietf-crypto-types, (urn:ietf:params:xml:ns:yang:ietf-tcp-server?revision=2019-07-02)ietf-tcp-server, (http://frrouting.org/yang/bgp-types?revision=2019-12-03)frr-bgp-types, (urn:ietf:params:xml:ns:yang:ietf-bgp-types?revision=2019-10-03)ietf-bgp-types, (urn:ietf:params:xml:ns:yang:ietf-tcp-common?revision=2019-07-02)ietf-tcp-common, (urn:ietf:params:xml:ns:yang:ietf-ssh-server?revision=2019-07-02)ietf-ssh-server, (http://frrouting.org/yang/eigrpd?revision=2019-09-09)frr-eigrpd, (urn:ietf:params:xml:ns:yang:ietf-netconf-server?revision=2019-07-02)ietf-netconf-server, (urn:ietf:params:xml:ns:yang:ietf-tls-common?revision=2019-07-02)ietf-tls-common, (http://frrouting.org/yang/isisd?revision=2020-04-06)frr-isisd, (urn:ietf:params:xml:ns:yang:ietf-interfaces?revision=2018-02-20)ietf-interfaces, (urn:ietf:params:xml:ns:yang:ietf-ssh-common?revision=2019-07-02)ietf-ssh-common, (http://frrouting.org/yang/bfdd?revision=2019-05-09)frr-bfdd, (http://www.sysrepo.org/yang/sysrepo-monitoring?revision=2020-04-17)sysrepo-monitoring, (http://frrouting.org/yang/frr-deviations-bgp-datacenter?revision=2019-12-03)frr-deviations-bgp-datacenter, (urn:ietf:params:xml:ns:yang:ietf-datastores?revision=2018-02-14)ietf-datastores, (http://www.sysrepo.org/yang/sysrepo?revision=2020-01-15)sysrepo, (http://frrouting.org/yang/routing?revision=2019-08-15)frr-routing, (urn:ietf:params:xml:ns:yang:ietf-tls-server?revision=2019-07-02)ietf-tls-server, (urn:ietf:params:xml:ns:yang:ietf-netconf-nmda?revision=2019-01-07)ietf-netconf-nmda, (http://frrouting.org/yang/igmp?revision=2019-11-06)frr-igmp, (http://frrouting.org/yang/route-map?revision=2019-07-01)frr-route-map, (urn:ietf:params:xml:ns:yang:ietf-truststore?revision=2019-07-02)ietf-truststore, (urn:ietf:params:xml:ns:yang:ietf-tcp-client?revision=2019-07-02)ietf-tcp-client, (http://frrouting.org/yang/interface?revision=2020-02-05)frr-interface, (urn:ietf:params:xml:ns:yang:ietf-keystore?revision=2019-07-02)ietf-keystore, (http://frrouting.org/yang/vrf?revision=2019-12-06)frr-vrf, (http://frrouting.org/yang/filter?revision=2019-07-04)frr-filter, (http://frrouting.org/yang/bgp?revision=2019-12-03)frr-bgp, (http://frrouting.org/yang/frr-bgp-rpki?revision=2019-12-03)frr-bgp-rpki, (urn:ietf:params:xml:ns:yang:ietf-origin?revision=2018-02-14)ietf-origin]
2020-12-15T20:04:14,879 | WARN  | remote-connector-processing-executor-11 | NetconfDevice                    | 287 - org.opendaylight.netconf.sal-netconf-connector - 1.11.2 | RemoteDevice{ark102}: Adding provided but not required sources as required to prevent failures
2020-12-15T20:04:14,888 | WARN  | remote-connector-processing-executor-1 | NetconfDevice                    | 287 - org.opendaylight.netconf.sal-netconf-connector - 1.11.2 | RemoteDevice{ark102}: Unable to build schema context, unsatisfied imports {RevisionSourceIdentifier [name=frr-bgp@2019-12-03]=[ModuleImportImpl [name=frr-bgp-bmp, revision=null, semanticVersion=null], ModuleImportImpl [name=frr-bgp-common, revision=null, semanticVersion=null], ModuleImportImpl [name=frr-bgp-neighbor, revision=null, semanticVersion=null], ModuleImportImpl [name=frr-bgp-peer-group, revision=null, semanticVersion=null], ModuleImportImpl [name=frr-bgp-common-structure, revision=null, semanticVersion=null], ModuleImportImpl [name=frr-bgp-common-multiprotocol, revision=null, semanticVersion=null]]}, will reattempt with resolved only
 

 
 

  • netconf capabilities it reports like : 
    <unavailable-capabilities xmlns="urn:opendaylight:netconf-node-topology"> <unavailable-capability> <capability>(http://frrouting.org/yang/bgp?revision=2019-12-03)frr-bgp</capability> <failure-reason>unable-to-resolve</failure-reason> </unavailable-capability> </unavailable-capabilities> <available-capabilities xmlns="urn:opendaylight:netconf-node-topology"> .... <available-capability> <capability-origin>device-advertised</capability-origin> <capability>(urn:ietf:params:xml:ns:yang:1?revision=2017-02-20)yang</capability> </available-capability> <available-capability> <capability-origin>device-advertised</capability-origin> <capability>(urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?revision=2011-06-01)ietf-netconf-with-defaults</capability> </available-capability> <available-capability> <capability>(http://frrouting.org/yang/igmp?revision=2019-11-06)frr-igmp</capability> </available-capability> <available-capability> <capability>(http://frrouting.org/yang/eigrpd?revision=2019-09-09)frr-eigrpd</capability>

    bgp is in unavailable-capability but others were in available-capability

  • feature:info odl-yanglib : 1.8.2
  • the ietf-netconf-monitoring:

<available-capability>
<capability-origin>device-advertised</capability-origin>
<capability>(urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?revision=2010-10-04)ietf-netconf-monitoring</capability>
</available-capability> *  I also checked cache/yang and found just parent yang was fetched, without any included submodules. then I manually copy these relative submodules to cache/yang, but the issue still same; * ODL version:0.12.2

  • OS: ubuntu 18.04.5
Comment by Robert Varga [ 01/Feb/22 ]

So the primary problem was the second WARNING, as the INFO is mostly harmless.
Closing this issue as Cannot Reproduce, with NETCONF-856 tracking the work to get rid of the INFO.

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