04-28-2018 07:44 PM - edited 03-01-2019 04:09 AM
Hi All ,
I recently started with NSO and looking for some help on a specific configuration I am trying to implement .
In my example configuration I made a service which deploys loopback 0 ip addresses on the devices , which works great for my learning example.
I am trying to modify the YANG below so that it takes the last octet of the management IP address configured on the device and appends it to the loopback0 address to automate the selection of loopback IP Address as well .
For example if the Management IP Address (/ncs:devices/ncs:device/ncs:name/address) is A.B.C.Z , I would like the loopback address to be 1.1.1.Z .
module loopback_deploy {
namespace "http://com/example/loopback_deploy";
prefix loopback_deploy;
import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
augment "/ncs:services" {
list loopback_deploy {
key "name";
ncs:servicepoint "loopback_deploy";
uses ncs:service-data;
leaf name {
type string;
}
leaf-list device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
leaf loopback-ip-address {
type inet:ipv4-address {
}
}
}
}
}
I tried to refer the loopback address using
leaf management_ip_address {
type leafref {
path "/ncs:devices/ncs:device/ncs:name/address";
}
}
But that throws an error
yang/loopback_deploy.yang:29: error: the node 'address' from module 'loopback_deploy' (in node 'device' from 'tailf-ncs') is not found
I would appreciate any help and pointed on how to achieve the desired configuration .
Regards,
Vikas
Solved! Go to Solution.
04-29-2018 08:56 PM
Generally YANG is used to define the schema. Some basic validation can also be specified (using must,when clauses). I prefer to put validation in the service's callbacks (create, preMod, postMod).
I would make the loopback_ip_address as operational data (config false;). If you want it to persist in the configuration database (CDB) then you can further add:
tailf:cdb-oper {
tailf:persistent true;
}
Then you can read mgmt-ip, mod and set the value in the service's callback.
Regarding python APIs and traversing the YANG definitions, doing CRUD (Create-Read-Update-Delete), nothing beats the docs/guide. Look up Maagic API in the "nso_development" guide. It is within Chapter-7 "Python API Overview".
04-29-2018 05:22 PM
Hi There,
Best to model the IP address for the loopback as operational data (and not as configuration data). Typically the config data for the service instance (service parameters) comes from a north-bound system (operator, CLI, API, etc). If the data is auto-generated or inferred then operational data may be a better fit (done using "config false;")
Also, I generally do not like to replicate data. The more copies, the more the maintenance and keeping it in sync.
XPATH may not be the easiest thing to master. Important to understand XPATH expansions. Also if you want to refer to a specific path then perhaps you can try:
leaf device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
leaf management_ip_address {
type leafref {
path "deref(../device)../address";
}
}
04-29-2018 06:17 PM
Thank you for the reply Bilal . This is more of a learning use case I am trying to implement .
In addition to your code provide above , below is the pseudo code of what I am trying to do . So basically if management_ip_address = 192.168.1.10 , The loopback_ip_address should become 1.1.1.10 , which will be referenced in the XML to be configured as lo0 IP Address.
leaf device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
leaf management_ip_address {
type leafref {
path "deref(../device)../address";
}
}
leaf loopback_ip_address {
type string {
"1.1.1." + regex_last_IP_octet(management_ip_address)
}
}
I am not sure if I am looking at the right place or of this is something which needs to be modeled directly in the XML template ?
Also to you comment on XPATH , do you have some good references / tools (Python libraries) which can help with building/looking up the right XPATH .
Thanks again !
Regards,
Vikas
04-29-2018 08:56 PM
Generally YANG is used to define the schema. Some basic validation can also be specified (using must,when clauses). I prefer to put validation in the service's callbacks (create, preMod, postMod).
I would make the loopback_ip_address as operational data (config false;). If you want it to persist in the configuration database (CDB) then you can further add:
tailf:cdb-oper {
tailf:persistent true;
}
Then you can read mgmt-ip, mod and set the value in the service's callback.
Regarding python APIs and traversing the YANG definitions, doing CRUD (Create-Read-Update-Delete), nothing beats the docs/guide. Look up Maagic API in the "nso_development" guide. It is within Chapter-7 "Python API Overview".
04-30-2018 03:03 AM
This does help , Thank you. trying to research based on your inputs , found this video which brings me closer to what I am trying to do
https://www.youtube.com/watch?v=4hCLAYbxjwE&t=
I was missing the python file in my packages , and the following commands int the video was very helpful .
ncs-make-package --service-skeleton python-and-template vikassri_auto_lo0_deploy`
04-30-2018 04:23 PM
If you get a chance, do look into the NSO formal training program - (Basic, Advanced and Operations).
The Advance training is now run for both Java and Python versions.
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