...
- 515 CPS-1 - Spike: Support multiple CM-Handles for NCMP Get Operation
- ARC Configuration Persistence Service (CPS) Component Description - CPS-NCMP ↔ DMI-Plugin Interface Details Jakarta-R10
Requirements
Functional
# | Interface | Requirement | Additional Information |
---|---|---|---|
1 | REST CPS(-NCMP)-E-05 | Support batch read operation (new) using an asynchronous response to on a client specified topic | payload includes list of cm handle ids |
2 | REST DMI-I-01 (TBC) | Support batch read operation (new) using an asynchronous response to client specified an internal topic | payload includes list of (associated for this plugin) cm handles ids with their private (additional, TBC) properties |
...
# | Error Scenario | Expected behavior |
---|---|---|
1 | DMI Not respond to initial synchronous request with normal HTTP timeout | Special Error message (Kafka event) including affected, and reason for all the handles in the message cm handles send to client topic detailing cm-handles (per dmi plugin) |
2 | Topic not supplied on CPS-E-05 | Return HTTP 501 (not implemented) |
3 | Client specided Topic is not configured | See open issue #9 |
4 | Non-existing cm-handle idSee open issue #10 | imilar message but different reason as specified #1 above |
Capabilities
# | Parameter | Expectation | Notes |
---|---|---|---|
1 | Response Time 1 Batch request | <2 seconds |
|
2 | Batch-size | 200-300 cm handles | No hardcoded limit |
3 | Response payload size | ?? KB | Performance test for cabilitie should be tested with this average response size |
4 | Maximum registered #cm handles | 20,000 | This will effect the internal query time |
5 | Supported # DMI PLugins | <30 (TBC) | This might effect processing time |
6 | Environment |
...
- Support for multiple resource identifies in one batch operation
- Support cache data batch requests: only passthrough datastores will be supported (see decision #2)
- NCMP does NOT keep track of request status to see if it is completed, amalgamate responses or anything like that. It wil simply forward responses from the internal topic to the client topic.
- Access control
Assumptions
# | Assumption | Notes |
---|---|---|
1 | "fields" and "scope" are proprietary options or not in the scope of this analysis. | agreed with kieran mccarthy ; these are optional parameters (name-value pairs) not interpreted by NCMP but can be interpreted by proprietary plugins |
2 | same xpath (resourceIdentifierInQuery) for all cm handles or different for each cm handle | agreed with kieran mccarthy ; if different resources are required on the same cm-handle the client wil send another (batch) request |
...
# | Issue | Notes | Decision | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
1 | Which operation(s) need support for multiple cm handles? |
if many what is the priority? | agreed with kieran mccarthy Only Get (read) (in future other operations might be support batch option too) | ||||||||
2 | Which datasources should be supported? | Do we need to support passthrough-only no-cached() data only ? | agreed with kieran mccarthy : all passthrough datastores will be supported Not implemented (yet) response, for other datastores | ||||||||
3 | URL pattern for NCMP bulk endpoints | Existing : /v1/ch/{cm-handle}/data/ds/{datastore-name} CPS Proposed : /v1/batch/data/ds/{datastore-name} ( include cm handles into payload / body and leave datastore into url) | agreed with kieran mccarthy : Follow the existing interfaces as much as possible for consistency and efficiency | ||||||||
4 | keep datastore, topic and optional parameters in the URL itself instead into body.
| CPS prefers keep interface similar as single cm handle interface (consistency and cost) Existing : ...&topic=topicParamInQuery | agreed with kieran mccarthy : Follow the existing interfaces as much as possible for consistency and efficiency | ||||||||
5 | support in ONAP DMI-plugin | agreed with Toine Siebelink : ONAP plugin can respond with not implemented yet code, | |||||||||
6 | Response always Async ie. topic is compulsory ? | Assume topic is compulsory (defined in OPenApi) → Response therefore wil be 400 if not supplied | Agreed with kieran mccarthy : Topic is optional but system will respond with 'Not implemented (yet when not specified or blank | ||||||||
7 | Should NCMP Amalgamate Async responses from DMI-Plugin before forwarding ? | step 6 in flow diagram | Agreed with kieran mccarthy : NCMP wil only forward to client topic no handling tracking or any responses or status of request | ||||||||
8 | Handle non responding dmi-plugin | Agreed with kieran mccarthy : | |||||||||
9 | Should (can) NCMP check if 'MyTopic' specified by client exist | Consider Access Control too. For now NCMP can log error. Client is responsible for topic setup | Agreed with kieran mccarthy : | ||||||||
10 | How to handle non-existing CM-Handled Handles (id) | Suggestions
| Agreed with kieran mccarthy : Additional error (messages) response with all cm-handles that cannot be resolved, also a separate error message wil be sent for each failed DMI | ||||||||
11 | Overlap/clash with Deutsche Telekom user story:
| discussed in weekly ONAP meeting the DT user story is affect CPS-Core interface (not NCMP) and the requirement is to execute a query over ALL cm-handles (cached only?!) instead of a given list of cm-handles (~anchors) |
...