05-08-2018 05:38 AM - edited 03-01-2019 04:09 AM
Hi,
Anyone could help me on why NED config YANG modules are not shown in “get-schema” via NSO NETCONF northbound API and how to add them? I have a northbound system that uses the “get-schema” option.
Roque
Solved! Go to Solution.
05-08-2018 05:52 AM
At first, it sounds kind of obvious that device YANG models should be possible to retrieve using get-schema. All YANGs should, right? But the devil's in the details.
As you know, when NSO compiles the device YANGs, it also rewrites them so that they augment /devices/device. The compiler still keeps the namespace string intact, however, so that the device will recognize the XML as its own. So if we let users retrieve these rewritten YANG models using get-schema, still having the same namespace string as the real device models, this could lead to confusion, and we'd be at fault. So this has been disabled.
There may be no perfect way of dealing with this, but of course some kind of alternate behavior could be devised. Before you write that feature request, however, consider what's going to be released in just a few weeks: common data models (CDM). With CDM in place, a given namespace may actually translate to multiple versions of YANGs. Which one should we return at get-schema? If get-schema was a bit weakly defined in the traditional NSO world, it's completely lost in the CDM world.
So I think get-schema for device models is problematic and will only get more so as our world grows away from the simple place where get-schema comes from. What you could do is to invent your own get-schema operation that takes relevant input and does the right thing in your environment.
05-08-2018 05:52 AM
At first, it sounds kind of obvious that device YANG models should be possible to retrieve using get-schema. All YANGs should, right? But the devil's in the details.
As you know, when NSO compiles the device YANGs, it also rewrites them so that they augment /devices/device. The compiler still keeps the namespace string intact, however, so that the device will recognize the XML as its own. So if we let users retrieve these rewritten YANG models using get-schema, still having the same namespace string as the real device models, this could lead to confusion, and we'd be at fault. So this has been disabled.
There may be no perfect way of dealing with this, but of course some kind of alternate behavior could be devised. Before you write that feature request, however, consider what's going to be released in just a few weeks: common data models (CDM). With CDM in place, a given namespace may actually translate to multiple versions of YANGs. Which one should we return at get-schema? If get-schema was a bit weakly defined in the traditional NSO world, it's completely lost in the CDM world.
So I think get-schema for device models is problematic and will only get more so as our world grows away from the simple place where get-schema comes from. What you could do is to invent your own get-schema operation that takes relevant input and does the right thing in your environment.
05-08-2018 06:12 AM
Hi Jan,
Thanks for your answer.
How are config modules different than other modules? I mean that there are modules for stats or ned-settings that augment /ncs:devices/ncs:device, just not the config tree.
Roque
05-08-2018 05:57 AM
Hello Roque,
This might not be perfect, but manually loading schema could be a workaround.
$ ncs --addloadpath packages/cisco-ios/src/yang/
Best regards,
Hiro
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide