[YANGTOOLS-583] Error when augmenting a mandatory node on a container in the same module Created: 12/Feb/16  Updated: 10/Apr/22  Resolved: 11/Mar/16

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 yangs.tgz    
External issue ID: 5335

 Description   

In one of the proposed BBF (Broadband Forum) models we are getting an error during parsing, which is, according to us a bug in the YANG parser. We are using the Lithium release currently (the original one, not one of the SRs).

I'm not allowed to attach the BBF model here, but I've reproduced the bug with a dummy model based on the example jukebox model, which I'm attaching here.

The situation is:

  • the jukebox-cd module is augmenting the "jukebox" container with an extra child container "cdcapable", which is a container with presence (this last point is crucial)
  • the jukebox-cd-sub submodule of the jukebox-cd module is then further augmenting that "cdcapable" container with a mandatory leaf "number-of-cds"

When we parse this via the YANG parser, we are getting the following error:

Error in module 'jukebox-cd-sub' at line 27: Error in augment parsing: cannot augment mandatory node number-of-cds
org.opendaylight.yangtools.yang.parser.util.YangParseException: Error in module 'jukebox-cd-sub' at line 27: Error in augment parsing: cannot augment mandatory node number-of-cds
at org.opendaylight.yangtools.yang.parser.impl.YangParserImpl.checkAugmentMandatoryNodes(YangParserImpl.java:882)
at org.opendaylight.yangtools.yang.parser.impl.YangParserImpl.resolveAugments(YangParserImpl.java:908)
at org.opendaylight.yangtools.yang.parser.impl.YangParserImpl.build(YangParserImpl.java:712)
at org.opendaylight.yangtools.yang.parser.impl.YangParserImpl.parseYangModelSources(YangParserImpl.java:358)
at org.opendaylight.yangtools.yang.parser.impl.YangParserImpl.parseYangModelsMapped(YangParserImpl.java:282)
at org.opendaylight.yangtools.yang.parser.impl.YangParserImpl.parseFiles(YangParserImpl.java:159)

According to us, and the people in the BBF working group, the given augment should be allowed.

In the RFC it says:
If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1).

But here the target node is in the same module (the augment is in a submodule of that module, but we assume that should not matter).

Also, according to the spirit of the RFC, the fact that the "cdcapable" container is a container with presence, makes that this is a safe augmentation which can't give a problem in clients that don't use the jukebox-cd module (the case of a container without presence is also not forbidden by the letter of the RFC, but could indeed pose a problem for such clients).

Is our understanding correct, so that this is a bug in yang-tools?

 Comments   
Comment by Peter Verthez [ 12/Feb/16 ]

Attachment yangs.tgz has been added with description: Example model

Comment by Robert Varga [ 12/Feb/16 ]

Since the augment is within the same module, I think this is a bug. Can you check if this is reproducible with Beryllium RC3 and/or Lithium SR3, please?

Comment by Peter Verthez [ 12/Feb/16 ]

I encountered the same bug in Lithium SR3 (which is why we didn't upgrade to it yet). I'll try Beryllium RC3.

Comment by Peter Verthez [ 12/Feb/16 ]

I couldn't find Beryllium RC3 in the Nexus repositories of Opendaylight, so I tried with RC2.2.

But this is apparently not backward compatible with Lithium (some classes are not found), so it would require changes in our application. So I couldn't test with that.

Comment by Igor Foltin [ 22/Feb/16 ]

The first part of the augment target path in submodule jukebox-cd-sub
(augment "/jbox:jukebox/jboxcd:cdcapable") targets imported module - that means
it is not in the same module.

Comment by Peter Verthez [ 29/Feb/16 ]

According to me the RFC defines the target node as the node to which new nodes are added (first paragraph in section 7.15 in the YANG RFC). And it then gives the constraint on the target node, not on any of its parent nodes.

Can you give a reference in the RFC that supports your statement?

Comment by Tony Tkacik [ 29/Feb/16 ]

Hi,

yes you are correct that YANG does not explicit mention this situation (augmenting augmentation) but according to the rule you cited

Following would be incorrect:

augment "/other:module" {

container foo {
leaf bar

{ mandatory true; }

}
}

and alternative writing of same would be correct:

augment "/other:module" {
container foo {}
}

augment "/other:module/foo" {
leaf bar

{ mandatatory true; }

}

In draft-netmod-rfc6020bis addition of mandatory nodes via augment was allowed given that
augmentation is conditional by when statement.

Could you open this issue on ietf-netmod mailing list? So we can get also opiniion from YANG authors?

Comment by Peter Verthez [ 29/Feb/16 ]

That example does not correspond to what I reported. It is rather:

augment "/other:module" {

container foo {
presence "some reason";
leaf bar

{ mandatory true; }

}
}

But I will send a mail on the ietf-netmod mailing list.

Comment by Peter Verthez [ 01/Mar/16 ]

See the answer from the ietf-netmod mailing list here:
http://www.ietf.org/mail-archive/web/netmod/current/msg15407.html

Comment by Tony Tkacik [ 01/Mar/16 ]

Ok, I added reasoning based on discussions, why such augment should be allowed:

Section 7.15 (https://tools.ietf.org/html/rfc6020#section-7.15)

> If the target node is in another module, then nodes added by the
> augmentation MUST NOT be mandatory nodes (see Section 3.1).

Section 3.1 (https://tools.ietf.org/html/rfc6020#section-3.1)

> A mandatory node is one of:
>
> o A leaf, choice, or anyxml node with a "mandatory" statement with
> the value "true".

> o A list or leaf-list node with a "min-elements" statement with a
> value greater than zero.
> o A container node without a "presence" statement, which has at
> least one mandatory node as a child.

Section 3.1 lists presence container as not mandatory node,
so adding presence container (using augmentations) could be considered
compatible, since clients not understanding augmenting model still would be able
to use / configure original model correctly.

Indeed this is bug, which affects Lithium, Beryllium and Boron.

Comment by Peter Kajsa [ 08/Mar/16 ]

fix: https://git.opendaylight.org/gerrit/#/c/35880/

Comment by Robert Varga [ 09/Mar/16 ]

Master merged, needs manual cherry-pick to beryllium.

Comment by Peter Kajsa [ 09/Mar/16 ]

fix stable/beryllium: https://git.opendaylight.org/gerrit/#/c/35985/

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