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/CONTROLLER-1511 controller <p>Recovery of data persisted in previous versions has an interesting problem, where we need to interpret stored data based on upgraded SchemaContext &#8211; without us knowing what the data actually was.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1511

CDS: persist SchemaContext

Improvement Confirmed Unresolved Unassigned Robert Varga Wed, 13 Apr 2016 11:29:55 +0000 Tue, 25 Jul 2023 08:24:09 +0000 clustering 0 3 <p>Actually, be cannot really rely on schema context assembly, because it is subject to implementation bugs, which means that we have no guarantee that the YANG models persisted by the old version will result in exactly the same schema context when assembled by the new version.</p> <p>In order to perform reasonable data migrations, the new version has to recover the same effective schema context.</p> <p>Hence we need to define a data format for the persisted data.</p> <p>I think the best option is to use XSD specification and emit XMLWriter events. This will give use XML output, which we can encode into binary using EXI. We can even do schema-informed encoding, as Exificient can turn XSDs into grammars.</p> <p>Since we are changing the snapshot format as part of BUG-5280, I will reserve a place for such a document in the new format, so we can retrofit it later without any breakage.</p> <p>Also linking updated BUG-2880 as it is blocking progress here.</p> <p>I think an acceptable solution is to store the YANG models and rely on SchemaContext assembly producing sufficiently-compatible result across major revision bumps.</p> <p>We actually everything we need to make this happen, as we can easily turn SchemaContext into a set of ModuleDeclaredStatements and stream them out as YANG text. Since we are bumping serialization format in <a href="https://jira.opendaylight.org/browse/CONTROLLER-1888" title="Update journal/snapshot/datastore version" class="issue-link" data-issue-key="CONTROLLER-1888"><del>CONTROLLER-1888</del></a> it makes sense to batch this change in. It requires a new payload, emitted when the schemacontext changes and update to the snapshot format (i.e. additional metadata class).</p> Blocks CONTROLLER-1448 CONTROLLER-1517 Development External issue ID 5718 External issue URL Issue Type Rank 0|i02r0v: