...
| Jira |
|---|
| server | ONAP Jira |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key | CPS-505 |
|---|
|
Requirements
Characteristics
| # | Interface(s) / Requirement | Capabilities | Notes |
|---|
| 1 | CPS-NCMP-I-01
Registration Performance | - NCMP should support discovery of up to 10k cmhandles
- NCMP should discovery cmhandles to READY state (with modules) at a rate of 4 per second assumptions :
- 100 cm handles per request
- 10 modules / cmhandle
- 95% module overlap across cmhandles
| - This KPI is for an E2E use-case depending on the performance of components outside NCP e.g. the 'modelAdapter'. Some assumption about the performance of this external dependency should be defined too.
- This KPI should include a cloud environment definition such as available resources like CPU and memory and same for the Postgress DB configuration.
|
| 2 | CPS-NCMP-I-01
Deletion Performance | Jira |
|---|
| server | ONAP Jira |
|---|
| columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key | CPS-1173 |
|---|
|
| |
|
| 3 | CPS-NCMP-I-01
Cm Handle Inventory Query Performance | Jira |
|---|
| server | ONAP Jira |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key | CPS-1494 |
|---|
|
|
| # | Parameter | Expectation | Notes |
|---|
| 1 | Response Time 1 | <40 second
<60 second (stretch) |
|
|---|
| 2 | Query complexity | 1 or more attributes on 1 Fragment (jsonb) object |
|
|---|
| 3 | Response payload size | TBD KB |
|
|---|
| 4 | Maximum registered #cm handles | 20,000 | This will effect the internal query time |
|---|
| 5 | Test Environment |
| Expand |
|---|
- CPS and NCMP
requests:
cpu: 2000m
memory: 2Gi
limits:
memory: 3Gi
cpu: 3000m
2. Postgres requests:
cpu: 4000m
memory: 1Gi
limits:
memory: 3Gi
cpu: 6000m
|
|
|
|---|
| 6 | Concurrent request | 1 |
|
|---|
| 7 | Request Frequency | Low no more than 1 per minute |
|
|---|
|
|
Background
When a new CM handle is encountered by the DMI plugin, NCMP is notified via REST. Once NCMP picks up the new CM handle it needs to determine what modules exist for it in the database and figure out which modules are missing. DMI plugin is contacted for all modules for this new node and they are matched to what CPS has. Missing modules are then retrieved from DMI and entered into the database.
...
| View file |
|---|
| name | DMI NCMP Model Sync.pptx |
|---|
| height | 250 |
|---|
|
High Level Proposal of Work to be done
- Call dmi–plugin rest endpoint to retrieve all modules on new node (depends
CPS-483 and CPS-531) - Call CPS-Core rest endpoint to get all existing modules in cps-core (depends CPS-506)
- Calculate difference (delta)
- Call dmi–plugin rest endpoint to retrieve missing modules
CPS-483 - Add missing modules to cps-core to anchor (cm handle) (depends CPS-508)
Implementation Proposal
Within the DMI plugin there is a method where cm handles are sent to a registration method in NCMP.
...
get cm handles from string
call dmi to get modules for this cmhandle
compare with cps and get delta
call dmi for delta modules
return Map<String, String> newYangResourcesModuleNameToContentMap
Alternative flow
DMI calls ncmp with new cm handle
ncmp sends back created
dmi then calls get new modules
get cm handles from string
call dmi to get modules for this cmhandle
compare with cps and get delta
call dmi for delta modules
return Map<String, String> new
