A NED has a version associated with it. A version consists of a sequence of numbers separated by dots ('.'). The first two number defines the major and minor version number, the third number defines the maintenance version number and any following numbers are patch release version numbers.
For instance, the 5.8.1 number indicates a maintenance release (1) on the minor release 5.8 and 5.8.1.1 indicates a patch release (1) on the maintenance release 5.8.1. Any incompatible YANG model change will require the major or minor version number to change, i.e. any 5.8.x version is to be backward compatible with the previous.
When a NED release is replaced with a later maintenance/patch release with the same major/minor version, NSO can do a simple data model upgrade to handle stored instance data in CDB. There is no risk that any data would be lost by this sort of upgrade.
On the other hand when a NED is replaced by a new major/minor release this becomes a NED migration. These are non trivial since the YANG model changes can result in loss of instance data if not handled correctly. With CDM the first and most important feature in NED migration is that both the old and new NED releases can be loaded at the same time and analysis of the YANG models and instance data can be performed before NED migration is attempted.
NED settings are YANG models augmented as config in NSO that
controls behavior of the NED. These setting are augmented
under /devices/global-settings/ned-settings,
/devices/profiles/ned-settings and
/devices/device/ned-settings. Traditionally
these NED settings have been accompanied by a
when expression specifying the ned-id
for which the settings are legal. With the introduction of
CDM such when expressions on specific
ned-ids are not recommended since ned-id will change with
NED releases.
Instead there is a need to introduce a 'family' identity
that becomes base for all NED releases for a certain family.
The when expressions can then use
derived-from syntax to be legal for all NED
releases in the family.
As stated above schema traversal works as before until a mount-point is reached in the path. At that point a lookup of the current mount-id (ned-id) is necessary to resolve any ambiguities in module name, prefix or XML namespace. Since the NED by definition works on devices under a NED any schema traversal in NED code falls under the latter case.
Pre CDM retrieving a CSNode from the Maapi Schema for a path
was as simple as calling the findCSNode(Namespace,
Path) function.
private MaapiSchemas.CSNode getCSNode(String path) throws MaapiException {
return schemas.findCSNode(Ncs.uri, path);
}
With CDM the original findCSNode(Namespace,
Path) still exists for backward compatibility but in
the NED code case all paths are under a mount-point and
hence this function will return an error that a lookup
cannot be performed. The reason for this is that a maapi
call to the NSO service is necessary to retrieve the
mount-id for the device. This is accomplished with a mount-id
callback MountIdCb(Maapi, Th) which takes a
Maapi instance and optionally a current transaction.
private MaapiSchemas.CSNode getCSNode(String path) throws MaapiException {
return schemas.findCSNode(new MountIdCb(this.mm, -1), Ncs.uri, path);
}