We want NSO Northbound API to properly encapsulate YANG model in a JSON object without changing anything for Yang developers.
As it currently stands there are three solutions (none of them great)
1. Make two network api calls: prefer not to make multiple network calls for same data as we have thousands of service instances for scalability reasons:
2. Change the yang model: causes issues and a big change for Yang Developers.
3. Force all North Bound Services to calculate what is the yang model config object by deduction (probably by removing standard service instance data fields). This is very brittle because it makes a big assumption that new service instance data fields won't be added. This can lead of silent bugs if fields like commit-queue get silently added to the root JSON object (which we have experienced without actually upgrading NSO). Northbound does not know and really should not care what new service instance data fields Southbound NSO will add to the service root object in the future. Northbound services needs the Yang Config object as a separate node in order to pass PUT/PATCH calls back to Southbound and really shouldn't have to calculate this.
Can you please fix this or explain whats the reasoning behind dumping yang model fields at the root object? It mixes two very different types of data: dynamic yang model and semi-fixed service-instance data..
We know about this config query parameter but we have thousands of services and we also need the non-config data (ex. devices). We do not want to make several network calls for the same data. It doesn't make sense to make multiple network calls and then join the data when NSO has all the data, it just needs to properly encapsulate it.
The whole of spirit of NSO is to abstract the config away for northbound applications.
I think this can be done if you just add a "container config" to all your services.
Also, you do have the filter parameter option and the NSO query API to test.
B.3.6. "filter" Parameter
The following URIs show some examples of notification filter
// filter = /event/event-class='fault'
// filter = /event/severity<=4
// filter = /linkUp|/linkDown
// filter = /*/reporting-entity/card!='Ethernet0'
// filter = /*/email-addr[contains(.,'company.com')]
// Note: The module name is used as the prefix.
// filter = (/example-mod:event1/name='joe' and
// To get notifications from just two modules (e.g., m1 + m2)
// filter=(/m1:* or /m2:*)
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...