https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-373 yangtools <p>Multiple users have taken up issue with the need to explicitly create structural containers. While this requirement is legitimate in and of itself, we can do much better and still be RFC6020 compliant.</p> <p>As it turns out, RFC6020 defines two flavors of containers: structural and presence. The difference is flagged by the "presence" keyword, as described at <a href="http://tools.ietf.org/html/rfc6020#section-7.5.5" class="external-link" target="_blank" rel="nofollow noopener">http://tools.ietf.org/html/rfc6020#section-7.5.5</a>.</p> <p>It is obvious we must not perform automatic lifecycle management for presence containers, since their existence has a semantic meaning. Non-presence containers, though, are present to give the data structure and can be freely removed if they have no children.</p> <p>Implementing this improvement will change the way the system behaves from the RESTCONF perspective, as empty containers will be removed automatically.</p> <p>Operating System: All<br/> Platform: All</p> YANGTOOLS-373

Data tree: automatic structural container lifecycle

Improvement Resolved Done Robert Varga Robert Varga Tue, 18 Nov 2014 13:05:26 +0000 Sun, 10 Apr 2022 18:35:25 +0000 Wed, 28 Oct 2015 17:21:14 +0000 0 5 <p><a href="https://git.opendaylight.org/gerrit/17030" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/17030</a></p> <p>From RESTCONF point of view, this constitutes a significant API change, as many empty containers will go missing. As Lithium was released, consumers are starting to rely on its behavior, which makes it harder for them to transition to the version of ODL where the implementation will appear.</p> <p>I think this improvement will need to be carefully documented, and it may be necessary to re-seek agreement on API freeze waiver. One of projects which may take a hit from this change is Integration, and indirectly every project which CSIT jobs use test suites not ready for this change.</p> <p>For this reason, the current Target Milestone (Lithium-1) may not be the best fit. I recommend setting the Target Milestone to one of the early Beryllium ones, perhaps to Beryllium-M2.</p> <p>Do you know of specific containers which would disappear and actually cause a problem (e.g. someone relying on their presence)?</p> <p>2015-09-14 11:25:54,942 | ERROR | lt-dispatcher-18 | LocalThreePhaseCommitCohort | 165 - org.opendaylight.controller.sal-distributed-datastore - 1.3.0.SNAPSHOT | Failed to prepare transaction member-1-txn-0 on backend<br/> java.lang.IllegalArgumentException: Subtree change with before-data not present at path /(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology<br/> at com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)<span class="error">&#91;64:com.google.guava:18.0.0&#93;</span><br/> at org.opendaylight.controller.md.sal.dom.store.impl.ResolveDataChangeEventsTask.resolveSubtreeChangeEvent(ResolveDataChangeEventsTask.java:268)<span class="error">&#91;145:org.opendaylight.controller.sal-inmemory-datastore:1.3.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.md.sal.dom.store.impl.ResolveDataChangeEventsTask.resolveSubtreeChangeEvent(ResolveDataChangeEventsTask.java:289)<span class="error">&#91;145:org.opendaylight.controller.sal-inmemory-datastore:1.3.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.md.sal.dom.store.impl.ResolveDataChangeEventsTask.resolveAnyChangeEvent(ResolveDataChangeEventsTask.java:120)<span class="error">&#91;145:org.opendaylight.controller.sal-inmemory-datastore:1.3.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.md.sal.dom.store.impl.ResolveDataChangeEventsTask.resolve(ResolveDataChangeEventsTask.java:62)<span class="error">&#91;145:org.opendaylight.controller.sal-inmemory-datastore:1.3.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.cluster.datastore.ShardDataTree.notifyListeners(ShardDataTree.java:108)<span class="error">&#91;165:org.opendaylight.controller.sal-distributed-datastore:1.3.0.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.cluster.datastore.SimpleShardDataTreeCohort.commit(SimpleShardDataTreeCohort.java:109)<span class="error">&#91;165:org.opendaylight.controller.sal-distributed-datastore:1.3.0.SNAPSHOT&#93;</span></p> <p>This clearly is not backwards-compatible. The problem is that SUBTREE_MODIFIED has had the behaviour of having a before-image, but with this change it does not, as the before-image is resolved from the original data tree (where it does not exist).</p> <p>We could switch to reporting a WRITE, but that will result in incorrect results when the DataTreeCandidate is replayed as a set of operations of a foreign DataTree, potentially losing data (since WRITE is imperative).</p> <p>It is definitely not a MERGE operation, at least not in the sense it is defined in its current deprecated form, as performing a MERGE on a foreign DataTree would result in more data appearing.</p> <p>An additional problem is that we cannot issue a DELETE modification when the container disappears, as again that would end up destroying foreign data which shares the subtree.<br/> We have two options here:</p> <p>1) modify the definition of SUBTREE_MODIFIED to say that the before-image is not necessarily present for structural containers and modify users accordingly<br/> 2) define a new modification type (STRUCTURAL, APPEAR+DISAPPEAR) for this behaviour, keeping SUBTREE_MODIFIED as is.</p> <p>Proposed API change: <a href="https://git.opendaylight.org/gerrit/26924" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/26924</a></p> <p><a href="https://git.opendaylight.org/gerrit/#/c/17030/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/17030/</a></p> Blocks BGPCEP-278 NETCONF-69 Duplicate BGPCEP-278 NETCONF-69 YANGTOOLS-272 Development External issue ID 2399 External issue URL Issue Type ODL SR Target Milestone Rank 0|i026tr: