cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
416
Views
5
Helpful
3
Replies
eric.gu
Beginner

North Bound API: Return Yang Model Config Data as an JSON Object

North Bound API - GET Service Instances 

 

Verb: GET

Endpoint: /restconf/data/tailf-ncs:services/{service_name}:{service_name}

 

The above endpoint fetches two types of data:

1. Standard Service Instance Data - These fields are standard but could evolve. Examples includes device-list,  log, service-name, service-key, commit-queue

2. Custom Service Yang Config Data - These fields are dynamic per the Specific Yang Service but examples could be interfaces, site_address, config_blah_, etc.

 

Issue:

Currently, the above endpoint returns a JSON response object in the following form:

 

{
    "service_name:service_name": [
        {
            "service-key": " ... ",
            "modified": { ... },
            "directly-modified": { ... },
            "device-list": [ ... ],
            "commit-queue": { ... },
            "log": { ... },
            "yang_variable_1": " ... ",
"yang_variable_2": " ... ",
"yang_varable..."
"yang_variable_n": " ... ", },]}

 

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.

 

Proposal:

 

{
    "service_name:service_name": [
        {
            "service-key": " ... ",
            "modified": { ... },
            "directly-modified": { ... },
            "device-list": [ ... ],
            "commit-queue": { ... },
            "log": { ... },
            "config: {. //THIS CONFIG SHOULD MIRROR PUT/PATCH PAYLOAD REQUEST JSON 
"yang_variable_1": " ... ",
"yang_variable_2": " ... ",
"yang_varable..."
"yang_variable_n": " ... ",
} },]}

 

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..

3 REPLIES 3
Nabsch
Beginner

Hello Eric,

 

To access to the the service instance config directly you can add this parameter  ?content=config

 

 

Endpoint: /restconf/data/tailf-ncs:services/{service_name}:{service_name}?content=config

 

 

Best Regards,

 

Nabil

Thank you.

 

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.

 

Thanks, 

 

Eric Gu

Principal Engineer

Verizon

rogaglia
Cisco Employee

Hi Eric,

 

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.

 

Roque

 

B.3.6.  "filter" Parameter

   The following URIs show some examples of notification filter
   specifications:

      // filter = /event/event-class='fault'
      GET /streams/NETCONF?filter=%2Fevent%2Fevent-class%3D'fault'

      // filter = /event/severity<=4
      GET /streams/NETCONF?filter=%2Fevent%2Fseverity%3C%3D4

      // filter = /linkUp|/linkDown
      GET /streams/SNMP?filter=%2FlinkUp%7C%2FlinkDown

      // filter = /*/reporting-entity/card!='Ethernet0'
      GET /streams/NETCONF?\
         filter=%2F*%2Freporting-entity%2Fcard%21%3D'Ethernet0'

      // filter = /*/email-addr[contains(.,'company.com')]
      GET /streams/critical-syslog?\
         filter=%2F*%2Femail-addr[contains(.%2C'company.com')]

      // Note: The module name is used as the prefix.
      // filter = (/example-mod:event1/name='joe' and
      //           /example-mod:event1/status='online')
      GET /streams/NETCONF?\
        filter=(%2Fexample-mod%3Aevent1%2Fname%3D'joe'%20and\
                %20%2Fexample-mod%3Aevent1%2Fstatus%3D'online')

      // To get notifications from just two modules (e.g., m1 + m2)
      // filter=(/m1:* or /m2:*)
      GET /streams/NETCONF?filter=(%2Fm1%3A*%20or%20%2Fm2%3A*)