[YANGTOOLS-770] Some augments are not being processed Created: 31/Mar/17  Updated: 10/Apr/22  Resolved: 10/Apr/17

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

Type: Bug
Reporter: Peter Verthez Assignee: Peter Kajsa
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 augmentbug.tgz    
External issue ID: 8126

 Description   

We are currently using a snapshot of Carbon of March 11.

Some augments in the model of one of our devices are not being picked up it seems. I have attached a minimal model to this ticket (which is the actual model, with all unnecessary parts removed, and with some types changed to string to avoid dragging in other models).

The structure is as follows:

  • ietf-interfaces defines:
  • container interfaces
  • list interface
  • bbf-sub-interfaces augments the interface with:
  • container frame-processing
  • container ingress-rule
  • list rule
  • container flexible-match
  • bbf-sub-interface-tagging has 2 augments:
  • an augment on flexible-match, which uses a grouping that defines:
  • choice vlan-tag-match-type
  • case match-all
  • leaf match-all
  • case untagged
  • leaf untagged
  • case vlan-tagged
  • list tag
  • leaf index
  • a second augment, on the "tag" added by the first augment, which again uses a grouping that defines:
  • container dot1q-tag -> this dot1q-tag is not found in the parsed model
    ...

The parsing is successful, no errors are generated, but the dot1q-tag of that last augment is not returned in the parsed model.

 Comments   
Comment by Peter Verthez [ 31/Mar/17 ]

Attachment augmentbug.tgz has been added with description: minimized model showing the bug

Comment by Peter Kajsa [ 03/Apr/17 ]

There is an issue with mandatory nodes. Yang parser complains that "leaf tag-type" cannot be added by the augment because "leaf tag-type" is mandatory and augment target is in different module (please see attached log entry below).

After quick investigation I think the leaf can be added, because "choice vlan-tag-match-type" is not mandatory node and in consequence "container match-criteria" is also not mandatory. So we need to fix the check of mandatory nodes in yang statement parser. We also need to increase severity of the log from debug to error.

org.opendaylight.yangtools.yang.parser.stmt.rfc6020.AugmentStatementImpl - Failed to add augmentation /home/pkajsa/eclipse_workspace/yangtools/yang/yang-parser-impl/target-ide/test-classes/bugs/bug8126/bbf-frame-classification.yang:128:16 defined at /home/pkajsa/eclipse_workspace/yangtools/yang/yang-parser-impl/target-ide/test-classes/bugs/bug8126/bbf-sub-interface-tagging.yang:28:4
org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException: An augment cannot add node 'tag-type' because it is mandatory and in module different than target [at /home/pkajsa/eclipse_workspace/yangtools/yang/yang-parser-impl/target-ide/test-classes/bugs/bug8126/bbf-frame-classification.yang:35:12]
at org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException.throwIf(InferenceException.java:47)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.AugmentStatementImpl$Definition.checkForMandatoryNodes(AugmentStatementImpl.java:301)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1080)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.AugmentStatementImpl$Definition.checkForMandatoryNodes(AugmentStatementImpl.java:298)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.AugmentStatementImpl$Definition.validateNodeCanBeCopiedByAugment(AugmentStatementImpl.java:267)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.AugmentStatementImpl$Definition.copyStatement(AugmentStatementImpl.java:249)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.AugmentStatementImpl$Definition.copyFromSourceToTarget(AugmentStatementImpl.java:224)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.AugmentStatementImpl$Definition$1.apply(AugmentStatementImpl.java:147)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.ModifierImpl.applyAction(ModifierImpl.java:100)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.ModifierImpl.tryApply(ModifierImpl.java:160)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.SourceSpecificContext.tryToProgress(SourceSpecificContext.java:350)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.SourceSpecificContext.tryToCompletePhase(SourceSpecificContext.java:328)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.completePhaseActions(BuildGlobalContext.java:359)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.executePhases(BuildGlobalContext.java:200)
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:189)
at org.opendaylight.yangtools.yang.stmt.StmtTestUtils.parseYangSources(StmtTestUtils.java:121)
at org.opendaylight.yangtools.yang.stmt.StmtTestUtils.parseYangSources(StmtTestUtils.java:138)
at org.opendaylight.yangtools.yang.stmt.StmtTestUtils.parseYangSources(StmtTestUtils.java:187)
at org.opendaylight.yangtools.yang.stmt.StmtTestUtils.parseYangSources(StmtTestUtils.java:177)
at org.opendaylight.yangtools.yang.stmt.StmtTestUtils.parseYangSources(StmtTestUtils.java:153)
at org.opendaylight.yangtools.yang.stmt.Bug8126Test.test(Bug8126Test.java:18)

Comment by Peter Kajsa [ 06/Apr/17 ]

https://git.opendaylight.org/gerrit/#/c/54365/

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