Model changes and Data Migration

jacob.collins — Fri, 01 Mar 2019 12:08:47 GMT

We have reviewed the Automatic Schema Upgrades and Downgrades within NSO documentation, there are rules we need to follow to allow the auto-upgrade to succeed. There will be times when yang models will break these rules and the usage of Using Initialisation Files for Upgrade will need to be used. The complexity of NSO and function pack releases and having to apply all incrementals releases suggests that we need a solid approach to upgrades.

We have found in several cases that upgrades will not allow us to update data. An example of a breaking change from our perspective is moving status out of mfcs-device into a new service point - to support automated onboarding. We have seen the example of Example 42, "New YANG module for the ServerManager Package", but this is a very simple change compared to a status that will trigger subscribers and kicker that trigger redeploys of packages.

Questions

1. If we have to update CDB outside of the specified rules (because of a fundamental issue with yang model), is there a set of tools or standard apis that can be used a in release to update data and model without lossing data due to a fast map causing data to be wiped?

2. How do we get more visibility of upgrade process working, so we can see where the failure happen? The devel.log doesn't give us a great deal more information of failures.

3. Is there a dry run upgrade process to view the outcome of an upgrade?

4. We are assuming that incremental releases use the Using Initialisation Files for Upgrade process, how do future update to function packs work with CDB and not cause upgrade conflicts or break custom models?

topic Model changes and Data Migration in NSO Developer Hub Discussions

Model changes and Data Migration