CPS-391 - Getting issue details... STATUS

Guiding Principles

1. NCMP REST Interface will follow/be inspired by RESTConf interface for easy acceptance of and transition to this interface
2. Will follow ONAP's RESTful API Design Specification 
3. The interface will include the concept of data-stores inspired by Network Management Datastore Architecture (NMDA) and as used in RESTConf
4. The application should be able to easily switch between 'pass-through' and other datastores (also identical rest endpoint and responses)

References

Follow principles/patterns of RESTCONF RFC-8040 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of yang-patch RFC-8072 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of RESTCONF NMDA RFC-8527 https://datatracker.ietf.org/doc/html/rfc8527

Requirements

Characteristics - WIP

It is proposed that reported characteristics will be used as a baseline for NCMP when agreed and sign-off.

Note

1. This is for mixed TCs
2. Single KPIs will be monitored in NCMP owned pipeline with our performance every day(2 hrs interval) - Performance
3. New BATCH KPI - TBD
4. Organise a call to walk through the code and TCs with //. Want to see the code of the Test Cases. Csaba Szabó to walkthrough TCs with CPS team
5. Check Registration & de-reg agree with // 

Open Questions

1. Concurrent which number are we agreeing to test, 10 parallel op. according to the input load, the average response time as mentioned in comment is 20 parallel op
2. DMI delay - We need feed back from ETH on this
3. Better to have R, W use cases separated as in the FS for both throughput and response time or should we merge this on NCMP
4. Check Registration - Kolawole Adebisi-Adeolokun  Refer to Michelle's email
5. Check DE-Registration if this was ever agreed

Ongoing Discussion

• Share Test cases per KPI with CPS. AP @Csaba Szabó X to walkthrough TCs with Toine & Daniel(CPS)

1. Functional Specification document.
1. Confluence: Configuration Handling Functional Specification.

                                                         i.      Current content shows mixed testcases, all TCs happening in parallel. AP @Csaba Kocsis  Clarify what is being run in parallel and update table accordingly.

                                                       ii.      AP @Csaba Kocsis update UseCase_0005_IdSearch_NoFilter & UseCase_0008_Search_NoFilter to merge the Input Load column to show total of  5 parallel requests.

                                                      iii.      AP @Csaba Kocsis Notify Product Engineering (Dagda) about the change.

1. AP , @Csaba Kocsis  , @Toine Siebelink, @Kolawole Adeolokun: Review the FS and identify if additional information is required. ONGOING

                                                         i.      23^rd April: FS reviewed and 2 comments added by Toine.

1. Question about FS and Stability test strategy – what is expected to be supported in parallel or what is expected to be tested in series? How is that decided? AP Michelle & @Csaba Kocsis

1. Can FS to be updated to define single / individual workload. Where can it be tested?  AP @Kieran Mccarthy A, @Csaba Kocsis, @Toine Siebelink

Synchronous single cm-handle pass-through (read) requests

Open Issues & Decisions

RESTCONF/NETCONF relationship

NCMP URI

NCMP URI format to follow below pattern

<OP>/ncmp/<v{vNumber}>/ch/<cmHandle>/<data|operations|{ncmpAction}>/ds/{datastore}?[rp:]{resourcePath}&{options}

Below table shows the proposed interface, actual implementation might deviate from this but can be accessed from

• Gerrit Source 
• Read-the-docs: https://docs.onap.org/projects/onap-cps/en/latest/design.html#offered-apis

Datastores

New datastores are defined for ncmp to access the CPS 'running' or 'operational' datastore.
Alternatively, the request can be sent directly to the 'device' itself (bypassing CPS datastores) using one of the 'passthrough-*' datastores options as below

The new ncmp datastores required for ONAP Release I include :

content=all

content=config

content=all

content=config

Datastore, Paths and Format Combinations for Read Operations

*Note Convert cpsPath to RESTConfPath wil only support 'absolute' cpsPath for conversion no query-type paths

Read Example

{ncmpRoot}/ncmp/v1/ch/<cmHandle>/data/ds/<datastore>/{dataResourceIdentifier}?fields={fieldsExpression}


URI :{ncmpRoot}/ncmp/v1/ch/node123/data/ds/ncmp-datastores:operational/TopElement[@id=1]/SomeFunction[@id=1]?fields=cell-model:Cell/attributes(attr1;attr2)
 
Header :
      Accept : application/yang-data+json
 
Response :
      200 OK
{
  "function-model:SomeFunction": [
    {
      "id": "1",
      "cell-model:Cell": [
        {
          "id": "Cell-001",
          "attributes": {
            "attr1": "value1",
            "attr2": "value2"
          }
        },
        {
          "id": "Cell-002",
          "attributes": {
            "attr3": "value3",
            "attr4": "value4"
          }
        }
      ]
    }
  ]
}

Works Items for above.

Datastore, Paths and Format Combinations for Write Operations

• Write operations are only supported on the ncmp-datastores:running and ncmp-datastores:passthrough-running datastores
• The Data Target for all write operation is DMI-Plugin
• Write operations are only supported for config=true data
• Fields and similar parameters are not supported for write operations

Write Example

Sync & Model API

Scenario : DMI notifies NCMP of new cmhandles
Method : POST
URI : {ncmpRoot}/ncmp/v1/ch/
Header :
    Content-Type: application/json

Request Body : {
      "dmiPlugin" : "onap.dmi.plugin", 
      "createdCmHandles" : [ {   "cmHandle" : "rf4er5454",
                                 "cmHandleProperties" :
                                   { "subSystemId" : "system-001" }
                             }, {..} ],
      "updatedCmHandles" : [ .. ],
      "removedCmHandles" : [ "node-1", "node-2" , ... ]
  }

{
  "modules": [
    {
      "moduleName": "", (Mandatory)
      "revision": "" (Optional)
    }
  ]
}

  [
        {
            "moduleName": "nc-notifications",
            "revision": "2008-07-14",
        },
        {
            "moduleName": "ietf-tls-server",
            "revision": "2016-11-02",
        },
        {
            "moduleName": "ietf-ssh-server",
            "revision": "2016-11-02",
        }
    ]

Success Response :
    HTTP/1.1 200 Ok
Date: Thu, 26 Jan 2021 20:56:30 GMT
Server: example-server
  { "cmHandles" : [ {
          "cmHandle" : "node-1",
          "cmHandleProperties " : { "subSystem" : "system-001" }
       } ]
   }

NCMP / DMI Overview