[YANGTOOLS-373] Data tree: automatic structural container lifecycle Created: 18/Nov/14 Updated: 10/Apr/22 Resolved: 28/Oct/15 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Description |
|
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. As it turns out, RFC6020 defines two flavors of containers: structural and presence. The difference is flagged by the "presence" keyword, as described at http://tools.ietf.org/html/rfc6020#section-7.5.5. 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. Implementing this improvement will change the way the system behaves from the RESTCONF perspective, as empty containers will be removed automatically. |
| Comments |
| Comment by Robert Varga [ 25/Mar/15 ] |
| Comment by Vratko Polak [ 10/Jul/15 ] |
|
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. 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. 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. |
| Comment by Robert Varga [ 07/Sep/15 ] |
|
Do you know of specific containers which would disappear and actually cause a problem (e.g. someone relying on their presence)? |
| Comment by Robert Varga [ 14/Sep/15 ] |
|
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 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). 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). 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. 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. 1) modify the definition of SUBTREE_MODIFIED to say that the before-image is not necessarily present for structural containers and modify users accordingly |
| Comment by Robert Varga [ 14/Sep/15 ] |
|
Proposed API change: https://git.opendaylight.org/gerrit/26924 |
| Comment by Robert Varga [ 28/Oct/15 ] |