[YANGTOOLS-771] IncorrectNestingException when writing to an augmented data-tree (BORON-SR3) Created: 17/Apr/17  Updated: 18/May/23

Status: Confirmed
Project: yangtools
Component/s: None
Affects Version/s: 1.0.3
Fix Version/s: None

Type: Improvement
Reporter: Satish Dutt Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


 Description   

I have created a project using boron-SR3 archetype. In one of the yang I have augmented a container. In the code I am trying to write the data to that container to the DataStore, but I am getting IncorrectNestingException exception. The same code is working fine in the boron stable project. Below are the yang and code snippets.

File1.yang :

module test-controller {
 yang-version 1;
 namespace "http://www.test.com/controllerconfiguration/core";
 prefix "testconfig";
 description "";
 revision "2016-09-22" { description "Initial revision of model"; }

 container controller {
 }
}

 

File2.yang :

module device-config {
 yang-version 1;
 namespace "urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:device-config";
 prefix "deviceconfig";
 revision "2016-09-28" { description "Initial revision of connector configuration model"; }
 
 import test-controller { prefix testconfig; revision-date 2016-09-22; }

 import yang-ext { prefix ext; }

 import ietf-inet-types { prefix "inet-types"; revision-date 2013-07-15; }

grouping controller-common-group {
 container version-info {
 leaf version
{ type string; mandatory true; description "Controller version."; }
}
}
 

 

/*

Augumented
 */
 augment "/testconfig:controller"
 Unknown macro: { ext}
}

 

File3.java :

VersionInfoBuilder versionInfoBuilder = new VersionInfoBuilder();
 versionInfoBuilder.setVersion("17.1.1.1");
 InstanceIdentifier<VersionInfo> in = InstanceIdentifier.create(Controller.class)
 .augmentation(ControllerMgmtAugmentation.class).child(ControllerCommonMgmt.class)
 .child(VersionInfo.class);
 WriteTransaction writeTranaction = dataBroker.newWriteOnlyTransaction();
 writeTranaction.merge(LogicalDatastoreType.OPERATIONAL, in, versionInfoBuilder.build(), true);
 writeTranaction.submit();

File4.java :

 

public interface ControllerMgmtAugmentation
 extends
 DataObject,
 Augmentation<Controller>
{ /** * Controller version and backup details. * * * * @return <code>org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.controller.config.sal.clustering.it.device.config.rev160928.controller.ControllerCommonMgmt</code> <code>controllerCommonMgmt</code>, or <code>null</code> if not present */ ControllerCommonMgmt getControllerCommonMgmt(); }

 

LOG Traces :

2017-04-14 17:33:17,565 | ERROR | on-dispatcher-34 | DataTreeChangeListenerActor | 176 - org.opendaylight.controller.sal-distributed-datastore - 1.4.3.Boron-SR3 | Error notify
 ing listener org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataTreeChangeListenerAdapter@85aac52
 org.opendaylight.yangtools.binding.data.codec.impl.IncorrectNestingException: Class interface org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.controller.config.sal
 .clustering.it.device.config.rev160928.ControllerMgmtAugmentation is not valid child of interface org.opendaylight.yang.gen.v1.http.www.test.com.controllerconfiguration.core.rev160
 922.Controller
 at org.opendaylight.yangtools.binding.data.codec.impl.IncorrectNestingException.create(IncorrectNestingException.java:28)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.3.
 Boron-SR3]
 at org.opendaylight.yangtools.binding.data.codec.impl.DataContainerCodecContext.childNonNull(DataContainerCodecContext.java:180)[74:org.opendaylight.mdsal.binding-dom-codec
 :0.9.3.Boron-SR3]
 at org.opendaylight.yangtools.binding.data.codec.impl.DataObjectCodecContext.bindingPathArgumentChild(DataObjectCodecContext.java:184)[74:org.opendaylight.mdsal.binding-dom
 -codec:0.9.3.Boron-SR3]
 at org.opendaylight.yangtools.binding.data.codec.impl.BindingCodecContext.getCodecContextNode(BindingCodecContext.java:127)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.
 3.Boron-SR3]
 at org.opendaylight.yangtools.binding.data.codec.impl.BindingCodecContext.newWriter(BindingCodecContext.java:104)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.3.Boron-SR
 3]
 at org.opendaylight.yangtools.binding.data.codec.impl.BindingNormalizedNodeCodecRegistry.toNormalizedNode(BindingNormalizedNodeCodecRegistry.java:102)[74:org.opendaylight.m
 dsal.binding-dom-codec:0.9.3.Boron-SR3]
 at org.opendaylight.controller.md.sal.binding.impl.BindingToNormalizedNodeCodec.toNormalizedNode(BindingToNormalizedNodeCodec.java:135)[146:org.opendaylight.controller.sal-
 binding-broker-impl:1.4.3.Boron-SR3]
 at org.opendaylight.controller.md.sal.binding.impl.AbstractWriteTransaction.merge(AbstractWriteTransaction.java:53)[146:org.opendaylight.controller.sal-binding-broker-impl:
 1.4.3.Boron-SR3]
 at org.opendaylight.controller.impl.ConnectorDTCL.onDataTreeChanged(ConnectorDTCL.java:41)[179:org.opendaylight.controller.test-impl:0.1.0.SNAPSHOT]
 at org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataTreeChangeListenerAdapter.onDataTreeChanged(BindingDOMDataTreeChangeListenerAdapter.java:41)[146:org.openda
 ylight.controller.sal-binding-broker-impl:1.4.3.Boron-SR3]
 at org.opendaylight.controller.cluster.datastore.DataTreeChangeListenerActor.dataChanged(DataTreeChangeListenerActor.java:58)[176:org.opendaylight.controller.sal-distribute
 d-datastore:1.4.3.Boron-SR3]
 at org.opendaylight.controller.cluster.datastore.DataTreeChangeListenerActor.handleReceive(DataTreeChangeListenerActor.java:40)[176:org.opendaylight.controller.sal-distribu
 ted-datastore:1.4.3.Boron-SR3]
 at org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:26)[170:org.opendaylight.controller.sal-clustering-commons:1.4.
 3.Boron-SR3]
 at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:165)[158:com.typesafe.akka.actor:2.4.7]
 at akka.actor.Actor$class.aroundReceive(Actor.scala:484)[158:com.typesafe.akka.actor:2.4.7]
 at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:95)[158:com.typesafe.akka.actor:2.4.7]
 at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)[158:com.typesafe.akka.actor:2.4.7]
 at akka.actor.ActorCell.invoke(ActorCell.scala:495)[158:com.typesafe.akka.actor:2.4.7]
 at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)[158:com.typesafe.akka.actor:2.4.7]
 at akka.dispatch.Mailbox.run(Mailbox.scala:224)[158:com.typesafe.akka.actor:2.4.7]
 at akka.dispatch.Mailbox.exec(Mailbox.scala:234)[158:com.typesafe.akka.actor:2.4.7]
 at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)[154:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
 at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)[154:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
 at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)[154:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
 at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)[154:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8]
 2017-04-14 17:36:43,318 | WARN | ssionScavenger-4 | teInvalidatingHashSessionManager | 199 - org.ops4j.pax.web.pax-web-jetty - 3.2.9 | Timing out for 1 session(s) with id 1hhckm7x
 1lje1zujilxde8pq1
 2017-04-14 17:36:43,320 | WARN | ssionScavenger-4 | teInvalidatingHashSessionManager | 199 - org.ops4j.pax.web.pax-web-jetty - 3.2.9 | Timing out for 1 session(s) with id 1eo5yv73
 psibrvwqf3rjsmepy

 Comments   
Comment by Martin Ciglan [ 18/Apr/17 ]

Can you re-try with latest stable/carbon branch? Thanks.

Comment by Martin Ciglan [ 19/Apr/17 ]

and post logs

Comment by Satish Dutt [ 19/Apr/17 ]

(In reply to Martin Ciglan from comment #2)
> and post logs

The same issue is observed in the master branch, which I presume must be the Carbon branch

Comment by Martin Ciglan [ 19/Apr/17 ]

Could you post complete logs from master? Thank you.

Comment by Satish Dutt [ 24/Apr/17 ]

Hi All,

I have analysed the root cause for this issue. The YANG RFC 6020 states that "If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes". So if we analyse the bug reported with this understanding, we can see that 'version' is a mandatory node in a different module, which is being augmented to 'controller' node present in a different module. So this is an violation as per RFC. Till the BoronSR1 this validation was not honored, and from BoronSR3 this is being honored. Unfortunately Yangtools should have thrown this validation as an ERROR instead of reporting as an WARNING and making the build successful and causing this issue during the runtime. So ideally this bug should be moved to the Yangtools project.

Regards
-Satish

Comment by Martin Ciglan [ 24/Apr/17 ]

thanks for clarifying this, moving to Yangtools.

Igor, Peter - we need fix for master and cherry-picks for Carbon & Boron too.

Comment by Peter Kajsa [ 24/Apr/17 ]

(In reply to Satish Dutt from comment #5)
> Hi All,
>
> I have analysed the root cause for this issue. The YANG RFC 6020 states that
> "If the target node is in another module, then nodes added by the
> augmentation MUST NOT be mandatory nodes". So if we analyse the bug reported
> with this understanding, we can see that 'version' is a mandatory node in a
> different module, which is being augmented to 'controller' node present in a
> different module. So this is an violation as per RFC. Till the BoronSR1 this
> validation was not honored, and from BoronSR3 this is being honored.
> Unfortunately Yangtools should have thrown this validation as an ERROR
> instead of reporting as an WARNING and making the build successful and
> causing this issue during the runtime. So ideally this bug should be moved
> to the Yangtools project.
>
> Regards
> -Satish

Hi,

it is intended behavior to log it as a warning, because in such case we still want to continue with creation of a SchemaContext.

BR
Peter.

Comment by Satish Dutt [ 24/Apr/17 ]

Hi Peter,

If just the warning is shown and is continued during the yangtools execution phase, it causes an issue during the runtime. In the runtime, IncorrectNestingException will be thrown, whenever the access is made to the nodes which are augmented to the target nodes of some other module. So it would be best during the yangtools execution phase, that this is thrown as an Error and abort. This will enable the user to fix his yang model which violates the RFC, rather than to get an exception during the runtime.

-Satish

Comment by Peter Kajsa [ 25/Apr/17 ]

Hi,

I agree with you, but this behavior has been requested by the ODL community due to a lot of not entirely valid augments in yang models (e.g. augments into unknown nodes in tailf's models etc.). So they requested a less strict yang parser due to these "not critical" errors in augments.

So please you can open a new discussion about this issue in community and if a new consensus is made, we are able to fix this very quickly.

I downgrade severity of the bug to normal, because it is definitely not a blocker.

BR
Peter.

Comment by Robert Varga [ 29/Jun/17 ]

While I agree, I think we can strike some middle ground.

We really want to control strictness of the parser code (i.e. fail build instead of a warning). This can be controlled on a per-pom.xml basis using maven configuration, which would be passed down as yang-parser-impl configuration.

This can then make it first an opt-in feature and once we stabilize augments vs. extensions, we can promote it to an opt-out feature.

Changing to an improvement and slightly bumping the priority, as this should be pretty easy to do.

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