Closed rdpravin1895 closed 5 years ago
Unfortunately napalm-yang is using an older revision of the model.
In addition, I don't have the cycles to keep maintaining this project but if someone wants to step in and fork the project I will gladly hand it over. Otherwise, I'd suggest tuning in into some of the work networktocode is releasing as it overlaps with this project (which I also developed).
https://www.networktocode.com/blog/post/open-source-model-driven-network-programmability/ https://www.networktocode.com/blog/post/yangify-is-released/
Unfortunately I don't have the cycles to keep maintaining this project so as of now it's officially abandoned. If someone wants to fork the project and maintain it don't hesitate to contact me to add a link to the fork and direct existing and new users to the new fork. However, I'd recommend checking the following alternative:
Yangify has a cleaner interface that is easier to maintain and happens to be orders of magnitude faster and also more memory efficient.
If you are an existing user of napalm-yang and are worried about this announcement and/or want help migrating to some other project don't hesitate to contact me.
We are trying to validate the junos interfaces napalm-yang config data with the openconfig-interfaces yang, but faced some issues when doing so. Junos openconfig-interfaces parser for config data has the following structure:
But according to the openconfig-interfaces yang, there is no "name" key inside the config part of subinterface list.
The key "name" is present only in the operational data. Due to this, the data validation fails. Should this be fixed?