In general NSO and NED upgrades can be performed independently. I typically do that to limit the impact of changes and focus on fixing one problem at a time in case there are any.
I do not have personal experience with the cisco-ios* CLI NEDs, but I do know NSO 5.2.1 has a problem with the /devices/device/migrate action, if the NED involved in the migration uses set-hooks. The first version where the migrate action reliably worked for me was 5.3.1. You mention you plan on upgrading NSO to 5.2.3.3. I did not check this version, but here is the relevant changelog entry from 5.3.1:
- ncs: The /devices/device/migrate action does no longer call set-hooks
when copying the running config from the device.
A number of cases are now corrected where the migrate action crashed or
set service meta-data incorrectly on backwards compatible data model
changes.
(ENG-22894, RT:40385, RT:40429, RT:40443, PS-35465, PS-35511, PS-35525)
I actually ended up having to use NSO 5.3.2 due to poor performance in startup times on schema upgrade, but that is besides the point :)
Apart from that, I would add these steps:
- Before loading the new NEDs in the production environment, make sure your templates (and code) can handle both versions. NSO will warn about incompatible schema changes (like changing a leaf to a container). Those will need to be handled with <?if-ned-id?> template tags. This step also includes making sure the service configuration is equivalent (or a superset) when using the new NED version.
- After executing migrate successfully, affected service instances should be re-deploy reconcile'd because:
- The forward-diff will be rendered invalid in case of incompatible changes to the device model. This for example shows up in get-modifications not working.
- The backpointers & refcounts will not add up to a service instance owning the parts of the device configuration that uses a new schema. This happens when you make your service packages compatible with both versions of the model and sync-from the configuration. For example, (I'm making this up) you use a leaf ip-address in NEDv1, but it has been renamed to primary-ip-address in NEDv2 data model, even though it actually configures the same CLI command. Even if you update your service(s) to use the new name, the configuration will not be owned just by the service instance(s), but will start off with an initial refcount of 1, after the initial sync-from during execution of migrate.
Also note that executing migrate does an implicit sync-from anyway.
