[YANGTOOLS-813] null module reference in relative leafref in openconfig model with deviation Created: 26/Sep/17  Updated: 10/Apr/22  Resolved: 06/Aug/18

Status: Resolved
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.5

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

Operating System: All
Platform: All

Attachments: File answer.json     Text File error.log     File hellomessage.rtf     Text File karaf.log    
External issue ID: 9214

 Description   

we're hitting a null module reference in an openconfig model (openconfig-interfaces).

I'm seeing this in Carbon-SR1 and in Master.

the device YANG model (openconfig-interfaces) has a deviation in IOS XR that impacts a leaf with a relative leafref in. The error we hit seems to be caused by a relative leafref.

the deviation is:

deviation /ocif:interfaces/ocif:interface/ocif:subinterfaces/ocif:subinterface/ocif:config/ocif:unnumbered

{ deviate not-supported; }

that corresponds to this in the openconfig model:

leaf unnumbered {
type leafref

{ path "../../index"; }

description
"Indicates that the subinterface is unnumbered, and provides
a reference to the subinterface that provides the IP
address information (v4, v6 or both) for the current
subinterface.";
}

logs (from master - enhanced with extra debugs) attached.

I added these lines in the relative leafref case in method getBaseTypeForLeafRef in SchemaContextUtil.java:

LOG.debug("parent module {}", parentModule);
LOG.debug("schema context {}", schemaContext);
LOG.debug("schema {}", schema);

these lines are getting triggered and show a null parent module (resulting from the previous line):

Module parentModule = findParentModule(schemaContext, schema);

 Comments   
Comment by Giles Heron [ 26/Sep/17 ]

added a few more logs. we're searching for the right module/revision. But seems that the schema context is incorrect as can't see openconfig-interfaces in there at all. Maybe we're looking in the controller context rather than the mounted context for some reason?

Comment by Peter Kajsa [ 27/Sep/17 ]

I'm sorry, but I don't see any logs attached. Please can you attach them. Thanks.

Comment by Giles Heron [ 27/Sep/17 ]

Attachment error.log has been added with description: log snippet

Comment by Peter Kajsa [ 03/Oct/17 ]

I have been testing this issue in different ways from yangtools point of view, but it always works fine as far as Yangtools is concerned. Target of leafref is resolved correctly and base type for leafref is also resolved correctly. Maybe there is some problem before yangtools.. or are we sure there are not any other deviations (except the mentioned cisco-xr-openconfig-interfaces-deviations.yang) related to openconfig-interfaces module (especially that could affect leafref target in some way) ?

Comment by Peter Kajsa [ 11/Oct/17 ]

I have discussed this issue with netconf guys and they have the following questions.
What exactlty are the steps to reproduce this bug (what reads are you performing or etc.) ?
They have asked for whole log when a device is connecting (with enabled DEBUG on org.opendaylight.netconf.sal.connect.netconf) in order to see hello report.

Thanks.

Comment by Matthieu Cauffiez [ 14/Nov/17 ]

Added hellomessage, karaf log and json answer
Matthieu

Comment by Robert Varga [ 20/Nov/17 ]

The exception seems to point to incorrect data format:

Caused by: java.lang.IllegalStateException: Schema for node with name ipv4 and namespace http://openconfig.net/yang/interfaces/ip doesn't exist.
at com.google.common.base.Preconditions.checkState(Preconditions.java:733)[12:com.google.guava:22.0.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:366)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:297)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:373)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:373)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:297)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:373)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.read(XmlParserStream.java:373)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.parse(XmlParserStream.java:191)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.yangtools.yang.data.codec.xml.XmlParserStream.traverse(XmlParserStream.java:220)[68:org.opendaylight.yangtools.yang-data-codec-xml:1.2.0]
at org.opendaylight.netconf.sal.connect.netconf.schema.mapping.NetconfMessageTransformer.toRpcResult(NetconfMessageTransformer.java:196)[366:org.opendaylight.netconf.sal-netconf-connector:1.6.0]
... 36 more

https://git.opendaylight.org/gerrit/65716 adds more information, we do need the XML content from the device.

Comment by Robert Varga [ 03/Aug/18 ]

Giles, can you check if problem is still there?

Comment by Giles Heron [ 05/Aug/18 ]

Looks good for me on Oxygen SR2.   Less so if I go back to Carbon SR2.  So I guess it's fixed 

Comment by Balaji Varadaraju [ 02/Nov/18 ]

Can I  please know the exact gerrit patch that fixes this issue? I may need this for Carbon.  Thanks.

Comment by Robert Varga [ 02/Nov/18 ]

I don't have a clue, it must have been fixed as a side effect of some other issue.

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