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.
SW upgrade or migration is something you never can escape from so it's better to make it part of your process. The remaining challenge is to determine when to give up what has been working to secure your future needs. Martin and the NSO team will guide y...
There is not a single golden tool that fits all purposes simply because development processes and needs are different. Instead, pick the tooling you need from the Smörgåsbord and build your environment to suit your needs. Shashidhar will guide you throug...
How Verizon Streamlined NSO Development with Continuous Integration
This is a customer success story of how Verizon ITNUC builds a CI chain to streamline the NSO development process. The containerized NSO makes testing several NSO packages in para...
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...