Common Design Problems and Ways to Solve Them
Side Effects
"Side effects" is also sometimes known as auto-configuration (auto-config). Side effects happen when a device automatically changes some YANG modelled configuration data as a result of some other configuration data being modified by a NETCONF RPC. In other words, the change is not explicitly made in the RPC and the device itself decides to make additional configuration changes based on what is in the RPC. Side effects are common in CLI-based devices as it can free up users from entering boilerplate configuration but it is problematic for programmatic interfaces because the orchestrator/controller expects to have full control of the configuration. In cases where side-effects are a pure addition, you may be able to work around it in NSO by adding the side effects to the transaction. Another option is to sync-from after applying the config that result in side effects but this dramatically slows down the orchestrator.
In the device, it is best to remove the side effects completely (the optimal solution). If that simply is impossible, then minimize them, or don't do them for programmatic interfaces (NETCONF/RESTCONF/…) or hide auto-configured leaves from programmatic interfaces.
Aliasing
Aliasing occurs when configurable YANG nodes are visible in multiple YANG-modules.
Usually this happens because a device supports more than one YANG module "family" such as native models and OpenConfig models. If NSO modifies the configuration through one of the modules this shows up as a change in the other module as well and NSO thinks it’s out of sync.
The way to make this work with NSO is to not have overlapping YANG modules in the NETCONF NED. i.e. Create the NSO NETCONF NED using only one of the YANG module "families".
Invalid Empty Configuration
The set of YANG models for a device should be designed in such a way as to allow the system to power up in a properly configured state without any user intervention. This implies that an empty configuration should always be valid. If a leaf is made mandatory, it will require its value to be configured first before the system can reach a valid state.
Rather than making the leaf node mandatory, one way to get around the issue is to define a default value for it in the YANG data model. An alternative is to make its parent container optional or what is known as a presence container. This will allow the system to reach a valid configured state even when these leaf nodes are left unconfigured.