...
| # | Issue | Notes/Jira | Decision | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | What topic to use for client? | Topic provided by client as a parameter which will be injected into our environment and used for asynchronous requests sent back to client. | To be supplied by cient | ||||||||
| 2 | What topic to use for private DMI-NCMP? | e.g. ncmp-async-private but decision needs to be made with current best practices. Contact Fiachra Corcoran regarding ONAP conventions. Response was that there aren't any conventions to speak of but we would use dashes (i.e. my-new-topic) instead of dot notation (i.e. my.new.topic) for topic name | Proposed: ncmp-async-m2m | ||||||||
| 3 | Are adding a new REST endpoint for async or modifying an existing endpoint? | To facilitate asynchronous requests to DMI we will need to either create a new endpoint or modify existing endpoint to include /async flag. The second solution may not be backwards compatible. However creating a new endpoint solely for a flag is also not ideal. We could add async to list of options (but this might interfere with the purpose of /options. Additionally, considered adding a new endpoint for async which simply re-routes the response to the original endpoint while adding the logic for OK response to the client. However, would this lead to a change in the schema? If so, would this be backwards compatible?
| /ncmp/v1/data/ch/123ee5/ds/ncmp-datastore:*?topic=<topic-name> | ||||||||
| 4 | Agree URL for async once #2 is clarified | CPS R10 Release Planning#NCMPRequirements #11. Based on this additional path parameter we no longer require additional /async flag in url. | /ncmp/v1/data/ch/123ee5/ds/ncmp-datastore:*?topic=<topic-name> | ||||||||
| 5 | Passthrough request need to be able to handle different response types (using accept header) but the async option would have a fixed and possibly different response type. | CPS R10 Release Planning#NCMPRequirements #11. | We should, by default, be able to accept multiple contnet-types. | ||||||||
| 6 | Should we create a standalone app to demo or are tests sufficient? | CSIT tests may require more involved effort - perhaps we could add standalone app to nexus and use it as part of CSIT test? | see See #13 | ||||||||
| 7 | Do we need to persist the generated requestID? | We should be be stateless | No | ||||||||
| 8 | Error Reporting - Topic Correctness/Availability | At a minimum we should report to the client if a topic was not found or if the topic name was incorrect | In Scope | ||||||||
| 9 | Error Reporting - Kafka Issues | Issues such full buffer/queue, drop messages, failure not in scope | Out of scope | ||||||||
| 10 | Async Request Option using Messaging | See: https://wiki.onap.org/display/DW/CPS-821+Spike%3A+Support+Async+read-write+operations+on+CPS-NCMP+interface#CPS821Spike:SupportAsyncreadwriteoperationsonCPSNCMPinterface-AsyncRequestOptionusingMessaging(OutofScope) | Out of scope | ||||||||
| 11 | Do we actually require futures in this implementation proposal? | It could be argued that the need for futures is made redundant by the fact we call dmi from ncmp through rest and the response will be consumed via Kafka. What benefit would future give us in this case? | Not needed | ||||||||
| 12 | ID Generation | Which mechanism to use? Look at CPS-Temporal and follow to keep consistency | |||||||||
| 13 | Are there any Kafka specific environment variables or config variables to be set for this work? | We will need to add new topic for DMI → NCMP M2M Kafka - which file(s)? | 14 | Can robot framework verify if Kafka events have been Can robot framework verify if Kafka events have been sent/received | This would be less work and overhead (rather than creating/.maintaining client app) | UNDER INVESTIGATION | |||||
| 14 | 15Can Webflux do this work with less code/impl? | Sourabh Sourabh suggested using this to compliment our existing approach. By adding webflux we add an event loop to | synchronisesynchronize and access I/O connections to the database. | 16 | ONAP may be deprecating PLAINTEXT for Kafka. Strimzi Kafka might need to be used | 17 | I believe this does not impact us as the client is outside of our scope and how they wish to communicate with Kafka is up them. | No, It will compliment the design by adding an event loop for I/O synchronization and access | |||
| 15 | ONAP may be deprecating PLAINTEXT for Kafka. Strimzi Kafka might need to be used | UNDER INVESTIGATION |
Proposed Design
...
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- Modify REST endpoint to include param topic (1)
- Add logic to send response and request (2a & 2b)
- Add producer to DMI (implementation and config) (31 & 3b)
- Add consumer to NCMP (implementation and config) (4a)
- Add consumer Producer to NCMP (implementation and config) (4b)
- Demo & Test (5)
...
| Type | Method | Ease of implementation | Decision |
|---|---|---|---|
| UUID | | Easy | ~ |
| Custom | We generate our own | Medium - Hard | N |
| HTTP Request ID | ~ | ||
| Kafka ID | ~ |
How do CPS-Temporal perform ID Generation for Events?
Async Request Option using Messaging (Out of Scope)
...
This was for a future completely message driven solution (for now we start with a REST request that will generate an async message eventually. In future we could also send a message that will trigger the same.
Webflux
...
Investigation (Out of Scope)
...
| Info | ||||||||
|---|---|---|---|---|---|---|---|---|
This may need it's own study to determine improvements to operations like model sync. There is a spike planned to further investigate reactive programming in cps-core.
|
...
Kafka Strimzi Investigation
...
Can Robot Framework verify Kafka Events?
...
Demo/Test
...
Existing Groovy tests exist for Kafka in cps-service/src/test/groovy/org/onap/cps/notification
...