Details
-
Improvement
-
Status: Confirmed
-
Resolution: Unresolved
-
None
-
None
-
None
-
Operating System: All
Platform: All
Description
Recovery of data persisted in previous versions has an interesting problem, where we need to interpret stored data based on upgraded SchemaContext – without us knowing what the data actually was.
Distributed data store has access to the current global SchemaContext, as it is required for DataTree operation. Include a portable (either YIN- or YANG-based) copy of SchemaContext in the data store Snapshot and use that for initial recovery. Also perform an explicit snapshot when the SchemaContext changes.
This will allow us to restore the data store snapshot, irrespective of what the runtime software is, and then perform an explicit schema adaptation step, where we convert the data tree to our current running schema context.
Furthermore it will allow software-asymmetric cluster, such as those existing when a cluster is being upgraded node-by-node, without it having been shut down.
A final benefit is that SchemaContext will be available at the persistence layer, allowing us to perform schema-informed serialization and deserialization (including object de-duplication). This capability is needed to deal with heavily-aliased data, such as coming from BGP, which reuses NormalizedNode instances for equal path attributes.
Attachments
Issue Links
- blocks
-
CONTROLLER-1448 Optimize NormalizedNode streaming by using a shared dictionary
- Resolved
-
CONTROLLER-1517 Upgrading model leads to existing data in old model being flushed
- Resolved