Since tailf:symlink has been removed in Conf-D 7.5.x, my old yang model cannot be compiled.
What alternative option we can have as a replacement of tailf:symlink on container and list?
There is a detailed discussion on this in section 12.8 of the ConfD 7.4 User Guide. I will include some snippet of the recommendation here:
The usage of symlink is not recommended. If it is used, use it carefully. It can be made to work in some special cases, but some other use cases, described below, are problematic. In the problematic cases, tailf:link can often be used instead. See Section 12.8.1, “Discussion” for more details.
and
The YANG modules that the device publishes to the northbound clients define the API between the client and the device. Specifically, the YANG module defines the complete data tree for configuration and operational state.
One problem with tailf:symlink is that a client application (for example a Network Management System) cannot just ignore the statement, since it defines a subtree in the datastore. But since this is not a standard statement, third-party clients will ignore it. This means that when they talk to the device, they will not understand the subtree under the symlink.
Note that symlink is used to provide a different entry point to the same underlying data. If both the data model with the symlink and the target data model is being exposed at the same time to the client, this will be confusing to the client. A change in one part of the tree makes another part change automatically.
One solution to this problem is to make sure that the module with the symlink is not exposed to the client. Instead, publish the target module only.
Another solution to this problem is to not publish the target module, but instead use pyang to sanitize the module with the symlink. The sanitizing process replaces the symlink statement with a copy of the target subtree. Then publish the sanitized version of the module. Code and documentation for pyang are available at https://github.com/mbj4668/pyang/.
2 Likes