Best approach to convert this container to a list?
per request, I need to change my service to allow for multiple interfaces to be specified. Currently, I have a container named "interface" where I configure one interface. I am looking to restructure this container to be a list where the key is the interface type, number, and dot1q tag. Due to the ifType and if_number being nested within "device type" containers, I don't know of an easy way to use this structure in a list. I could remove all containers and validate interface type and number within the python code, but I would rather keep as much validation as possible within the YANG.
If you want those three leaves to be the keys, there is no way to keep the structure the same. As for validation, maybe you can combine the 'when' expressions and the enum values for 'ifType' into a single must expression, something like:
must "(...ned-id='cisco-iosxr' and ifType != 'fastethernet') or (...ned-id='cisco-ios' and ifType != Eth-Trunk) ..." etc.
Replicating the leafref will be difficult. Maybe you can use a completion point to supply the valid completions yourself, by reading the configured interfaces and the interface type from CDB? But of course, that does not prevent someone from providing a different value than what is offered as completions - ie., it does not fully mimic the behavior of a leafref. Still, might be an option.
Otherwise, I can't see an easy way to change the model as you want, and still preserve the same semantics/validation.
I just had an idea. I could keep the interface container and make three list: iOS, iosxr, Huawei and then add the uses subinterface_grouping inside each of those list. Finally, I would need to figure out the best way to pull out the different if_number leafs.
Any thoughts on this approach? I'll type it up when I get to my laptop.
It is best practice to avoid storing your secrets (e.g., passwords and shared keys) in plain text, either on NSO or on the device. In NSO, we support multiple encrypted data types that are encrypted using a local key. Similarly, many devices such as Cisco...
Cisco Developer Days, September 14-15, 2021
On Tuesday next week, we will open the doors to the 11th Cisco Developer Days!
If you have not registered for the free, virtual event, do it now!
What can you expect?
We have a packed 2-day agen...
In the blog post series called "Unlocking Performance in your NSO System" we talked about the need to measure performance and to profile the performance in order to identify bottlenecks. We didn't go into any details about how to do this. Last year at the...
Finally, as you may have seen in the News & Announcement, we have opened the landing page for the next Developer Days event in September! The September 14/15 event is the first in a series of three virtual events in the three regions (EMEAR/US/Asia Pa...
We are excited to announce that our call for speakers for our upcoming Developer Days events is open!
Automation is a journey in itself and no two journeys are alike. Planning and preparation are a must for any major project. Having an open mind to u...