[CONTROLLER-1497] Improve DataTreeModification pruning on recovery Created: 09/Mar/16  Updated: 13/Apr/16  Resolved: 13/Apr/16

Status: Resolved
Project: controller
Component/s: clustering
Affects Version/s: Beryllium
Fix Version/s: None

Type: Bug
Reporter: Tom Pantelis Assignee: Tom Pantelis
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 5485
Priority: Normal

 Description   

The PruningDataTreeModification prunes nodes based on namespace. This works fine when an entire schema namespace is removed.

But it fails if a schema element is removed but the namespace is still valid. Eg, given the following schema:

module test {
namespace "urn:test";
...
container container1 {
}

container container2 {
}
}

If container1 is removed, on persistence recovery, the PruningDataTreeModification tries to merge the node but it fails with a SchemaValidationFailedException. It then checks if the namespace(s) in the path are valid. If it isn't, it discards it with an "Invalid node identifier ..." message. But in this case the namespace is still valid so it assumes a child node was invalid and tries to prune the node tree. However the NormalizedNodePruner also checks namespaces so nothing is pruned and tries to merge it again which fails again with SchemaValidationFailedException. This gets propagated to akka and recovery fails rendering the Shard unusable.

What we need to do is check if the QNames in the path and nodes are valid, same as the data tree does. I prototyped a solution for this.

Another issue I found is that merge validates the structure but write doesn't. The SchemaValidationFailedException occurs later on ready. So we need to also catch SchemaValidationFailedException on ready and re-apply the modification tree with pruning.

I think it would be ideal and more efficient to do the pruning in the InMemoryDataTreeModification, i.e. a pruning version of it. But I think that would be part of a bigger effort for schema migration support.



 Comments   
Comment by Tom Pantelis [ 10/Mar/16 ]

Submitted https://git.opendaylight.org/gerrit/#/c/36013/

Generated at Wed Feb 07 19:55:42 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.