[YANGTOOLS-1443] Fix YangDataEffectiveStatement definition Created: 26/May/22  Updated: 12/Oct/22  Resolved: 12/Oct/22

Status: Resolved
Project: yangtools
Component/s: parser
Affects Version/s: 9.0.0, 8.0.6, 7.0.17
Fix Version/s: 10.0.0, 9.0.2, 8.0.8

Type: Bug Priority: High
Reporter: Peter Suna Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Creating EffectiveModelContext with DefaultYangParserFactory fails if any models use `yang-data` extension from ietf-restconf.yang. This issue could be related to ietf-restconf namespace "urn:ietf:params:xml:ns:yang:ietf-restconf", because if is changed EffectiveModelContext is successfully built.

[main] WARN org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext - Unexpected error processing source RevisionSourceIdentifier [name=test-bug@2017-07-27]. Please file an issue with this model attached.
java.util.NoSuchElementException: No value present
    at java.base/java.util.Optional.get(Optional.java:148)
    at org.opendaylight.yangtools.rfc8040.parser.YangDataEffectiveStatementImpl.<init>(YangDataEffectiveStatementImpl.java:40)
    at org.opendaylight.yangtools.rfc8040.parser.YangDataStatementSupport.createEffective(YangDataStatementSupport.java:123)
    at org.opendaylight.yangtools.rfc8040.parser.YangDataStatementSupport.createEffective(YangDataStatementSupport.java:36)
    at org.opendaylight.yangtools.yang.parser.spi.meta.AbstractStatementSupport.createEffective(AbstractStatementSupport.java:85)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.AbstractResumedStatement.createEffective(AbstractResumedStatement.java:124)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.AbstractResumedStatement.createEffective(AbstractResumedStatement.java:109)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementContextBase.createEffective(StatementContextBase.java:439)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.ReactorStmtCtx.loadEffective(ReactorStmtCtx.java:389)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.ReactorStmtCtx.buildEffective(ReactorStmtCtx.java:385)
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
    at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
    at org.opendaylight.yangtools.yang.parser.spi.meta.AbstractStatementSupport.buildEffectiveSubstatements(AbstractStatementSupport.java:139)
    at org.opendaylight.yangtools.yang.parser.rfc7950.stmt.module.ModuleStatementSupport.buildEffectiveSubstatements(ModuleStatementSupport.java:227)
    at org.opendaylight.yangtools.yang.parser.spi.meta.AbstractStatementSupport.createEffective(AbstractStatementSupport.java:83)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.AbstractResumedStatement.createEffective(AbstractResumedStatement.java:124)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.AbstractResumedStatement.createEffective(AbstractResumedStatement.java:109)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementContextBase.createEffective(StatementContextBase.java:439)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.ReactorStmtCtx.loadEffective(ReactorStmtCtx.java:389)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.ReactorStmtCtx.buildEffective(ReactorStmtCtx.java:385)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.transformEffective(BuildGlobalContext.java:261)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.buildEffective(BuildGlobalContext.java:211)
    at org.opendaylight.yangtools.yang.parser.stmt.reactor.CrossSourceStatementReactor$BuildAction.buildEffective(CrossSourceStatementReactor.java:224)
    at org.opendaylight.yangtools.yang.parser.impl.DefaultYangParser.buildEffectiveModel(DefaultYangParser.java:96)

 

 Comments   
Comment by Robert Varga [ 26/May/22 ]

What is the real-world example of this failure?
The 'anydata' example is invalid AFAICT, based on rc:yang-data's description:

          It MUST contain data definition statements
          that result in exactly one container data node definition.
          An instance of a YANG data template can thus be translated
          into an XML instance document, whose top-level element
          corresponds to the top-level container.
Comment by Peter Suna [ 26/May/22 ]

Yes, I found this inside yumaworks netconf-pro server. So if the model is invalid, why it works when I change namespace inside extension-model to "extension:model" or any other?

Comment by Robert Varga [ 26/May/22 ]

Simple: if you do that, then suddenly it no longer is "The RFC8040 yang-data Extension", but some random extension we know nothing about. RFC7950 Section 6.3.1 applies:

   The processing of extensions depends on whether support for those
   extensions is claimed for a given YANG parser or the tool set in
   which it is embedded.  An unsupported extension appearing in a YANG
   module as an unknown-statement (see Section 14) MAY be ignored in its
   entirety.  Any supported extension MUST be processed in accordance
   with the specification governing that extension.
Comment by Robert Varga [ 26/May/22 ]

It seems the spec is rather bad and based on this NETCONF WG thread the intent is that "container data node definition" be NOT interpreted with RFC7950 terminology. Specifically it seems that "container" is meant to say "interior node with a single instance", i.e. include anydata and anyxml and perhaps even single-element lists.

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