08-23-2019 01:00 AM - edited 08-23-2019 02:04 AM
Hi,
In my YANG file I've got several containers for different platforms;
For IOS-XR, I use the when statement to determine if it's an XR device. The NED ID string I can verify in the NED package meta data file:
container iosxr {
when "/ncs:devices/ncs:device[ncs:name=current()/../device]/ncs:device-type/ncs:cli/ncs:ned-id='cisco-ios-xr-id:cisco-ios-xr'" {
tailf:dependency "../device";
tailf:dependency "/ncs:devices/ncs:device/ncs:device-type";
}
For a Juniper device I've used a similar approach based on the netconf type. However, this doesn't work and the Juniper-Junos-example NED doesn't contain a NED-ID tag in the package meta data file so I use the ID from the NSO configuration.
container junos {
when "/ncs:devices/ncs:device[ncs:name=current()/../device]/ncs:device-type/ncs:netconf/ncs:ned-id='netconf'" {
tailf:dependency "../device";
tailf:dependency "/ncs:devices/ncs:device/ncs:device-type";
}
In this case it evaluates as false for a Juniper device. Any pointers?
08-23-2019 03:06 AM - edited 08-23-2019 03:11 AM
Hey,
show devices device YourDevice module | display xpath
Does this display name='junos' for you (it should)?
08-26-2019 01:38 AM
08-23-2019 09:09 AM
I'm curious why you are putting all this device-type specific code in to the Service model YANG.
Generally, a basic concept of NSO is to make the Service model abstracted from the device type and have the mapping code take care of the device-type specifics - preferably in the template. In this way the Northbound interaction with the Service model can remain the same even if the underlying device(s) change from one vendor to another - which is handled in the template by just adding a stanza in the template for the new device-specific configuration.
08-26-2019 12:49 AM - edited 08-26-2019 05:09 AM
I agree, however in this case one of the things I'm trying to achieve is to set some constraints in the model that prohibits the user from deploying services on interfaces that are used for other purposes than that of the service. For this I read out the information in the interface description.
In a perfect world, this would've been a standardised path to the element I need to collect information about - but it isn't :|
/J
08-27-2019 02:07 AM
Hello,
You can try to have a look at the capability(ies) of the device (with all the caveats mentionned before in the above answers):
admin@ncs devtools true
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# xpath eval /devices/device[name=\"alu-sr-0\"]/capability[uri='http://tail-f.com/ned/alu-sr'] /devices/device[name='neren100']/capability[uri='http://tail-f.com/ned/alu-sr'] admin@ncs(config)# xpath eval /devices/device[name=\"alu-sr\"]/capability[uri='http://tail-f.com/ned/alu-blah']
This should work better for CLI device than checking the CLI NED as in NSO 5.x the NED-ID will be version dependent so you would have to support multiple ned-id in your when statement for instance:
37 // may replace this with other ways of refering to the devices. 38 leaf device { 39 type leafref { 40 path "/ncs:devices/ncs:device/ncs:name"; 41 } 42 } 43 44 leaf dummy { 45 when "/ncs:devices/ncs:device[ncs:name=current()/../device]/ncs:capability[ncs:uri='http://tail-f.com/ned/alu-sr']"; 46 type inet:ipv4-address; 47 } 48 }
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