CPS-391Spike: Define and Agree NCMP REST Interface
https://lf-onap.atlassian.net/browse/CPS-391
Guiding Principles
NCMP REST Interface will follow/be inspired by RESTConf interface for easy acceptance of and transition to this interface
Will follow ONAP's RESTful API Design Specification
The interface will include the concept of data-stores inspired by Network Management Datastore Architecture (NMDA) and as used in RESTConf
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
Issues & Decisions
Issues | Notes | Decisions | ||
|---|---|---|---|---|
| 1 | 1 | KPI for De-registration of 100 CM-handles | This was mentioned. Was this ever agreed, is this a valid use case that needs to be covered together with the Registration ? | Not priority for now, but acceptable if we match the registration req. |
| 2 | 2 | DMI delay | Could we get some feedback on DMI-delays for other use cases as not mentioned in FS document | Awaiting for ETH feedback May 21, 2024 AP On @Kolawole Adebisi-Adeolokun and @Csaba Kocsis Jul 2, 2024 Provided |
| 3 | 3 | Number of instances In some cases, ETH have used 2 instances, can we verify the number of instances for each use case. Some of the req were defined per instance and resources used : Identify which of these ? | Agreed to; CPS use 1 instance currently, but should focus on aligning performance with 2 instances for all use case | Jul 9, 2024 @Kolawole Adebisi-Adeolokun @Csaba Kocsis |
| 4 | 4 | Input Load Distribution the CM-handle search and ID search | Currently has 5 parallel request between them distributed at 2.5 each. This fractional distribution isn't feasible for parallel processing; the load should be allocated as whole numbers. Load needs to be distributed at. Would it be acceptable to adjust this distribution to either 2 or 3 parallel requests each (and vice versa ) without any negative repercussions? Agreed to do 6 parallel request combined total and divide the load to 3 parallel request each | Jul 9, 2024 @Kolawole Adebisi-Adeolokun @Csaba Kocsis |
| 5 | Regarding CM-handle search and ID search | FS only identified Module performance, are there any testing done towards a combined search of properties and modules in a single query Confirmed no other testing was previously done on this..... CPS have the capabilities to do mixed testing. ETH tbc on if they want to consider this ( @Csaba Kocsis ) |
Requirements
Please note this section was added long after the implementation and focuses on characteristic and enhancements after this study only.
Characteristics
Operation | Concurrent requests/parallel | DMI Delay | Response size | Performance Requirement | Notes | Sign-Off | ||
|---|---|---|---|---|---|---|---|---|
| 1 | Registration of 50,000 CM-handles | 1 (requests are sequential) | 100 ms to get module references | N/A |
|
| May 21, 2024 @Csaba Kocsis @Toine Siebelink | |
| 2 | De-registration of 2,000 CM-handles | 1 (requests are sequential) | No Module delays | N/A |
| De-registration is currently not mentioned in Stone Tablet KPI or FS, however we have agreed to match the performance of registration for now as de-reg is also not a priority at this point in time | May 21, 2024 @Csaba Kocsis @Toine Siebelink @Kolawole Adebisi-Adeolokun | |
| 3 | CM-handle ID search with Module filter | 5 parallel request | N/A | 50,000 CM Handles i.e. | 2 seconds/operation |
| Jul 9, 2024 @Kolawole Adebisi-Adeolokun @Csaba Kocsis | |
| 4 | CM-handle search with Module filter | 5 parallel request | N/A | 50,000 CM Handles i.e. | 15 seconds/operation |
| Jul 9, 2024 @Kolawole Adebisi-Adeolokun @Csaba Kocsis | |
| 5 | Synchronous single CM-handle pass-through read | 4 (Parallel operations) | 300 ms | 5 KB | 25 request/second |
| ||
| 6 | Synchronous single CM-handle pass-through write (CUD) | 4 (Parallel operations) | 670 ms | 5 KB | 12.5 request/second |
| ||
| 7 | Batch/Bulk Read | 60 read request with 200 cmHandles each at 1 req/second. | 150 cmhandles/second |
| ||||
| 8 | 8 | CM change Notification Event |
|
|
Notes
This is for mixed TCs
Single KPIs will be monitored in NCMP owned pipeline with our performance every day(2 hrs interval) - Performance
Test cases 3 through 7 are to run in parallel.
Synchronous single cm-handle pass-through (read) requests
Parameter | Expectation | Notes | Sign-Off |
|---|---|---|---|
Average Response Size | 5KB | Shall not exceed 5KB | Dec 6, 2023 @Kolawole Adebisi-Adeolokun |
Concurrent request | 12 clients requests toward 1 NCMP simultaneously | 40ms of overhead on top of DMI latency for each requests, at most for NCMP request. This shall remain within 40ms for 12 parallel requests. Given the DMI delay below; this means up to 240 request per second | Dec 6, 2023 @Kolawole Adebisi-Adeolokun |
DMI Delay | 10ms | This is not in control of CPS. Assume DMI is 1.25 seconds average DMI response time for high latency, low latency =10 ms, this should also work for DMI Plugin. I.e 40ms ontop of the DMI. 1.25seconds+40ms= 1.29seconds | Dec 6, 2023@Kolawole Adebisi-Adeolokun |
Test Environment |
2. Postgres
| Dec 6, 2023 @Kolawole Adebisi-Adeolokun | |
Security | Disable Basic Authentication in Springboot | If configurable from application yaml, then it’s acceptable. | Dec 6, 2023 @Kolawole Adebisi-Adeolokun |