...
Jira | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Issues/Decisions
...
Color | Meaning |
---|---|
New/Open | |
Reopened | |
Agreed/Closed |
# | 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.by client as a parameter which will be injected into our environment and used for asynchronous requests sent back to client. | Update: After discussion with Fiachra Corcoran regarding Kafka-strimzi it has been agreed that we will define a topic for client responses in advance (defined upfront). After release K it is envisioned that auto creation of topics will be disbaled by default thus the client will have to use our predefined topic. Agreement on topic name outstanding ---------------------------------------------------------------------------------------
| |||||||
2 | What topic to use for private DMI-NCMP? | 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 | 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. | /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. | The async response can 'wrap' the native response inside a json object identical to the synchronous response | ||||||||
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 #13 | ||||||||
7 | Do we need to persist the generated requestID? | We should be be stateless | No - Further disc | ||||||||
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 | See: https://wiki.onap.org/display/DW/CPS-821+Spike%3A+Support+Async+read-write+operations+on+CPS-NCMP+interface#CPS821Spike:SupportAsyncreadwriteoperationsonCPSNCMPinterface-CanRobotFrameworkverifyKafkaEvents | ||||||||
13 | Can robot framework verify if Kafka events have been sent/received | This would be less work and overhead (rather than creating/.maintaining client app) Will need to verify if 3PP libraries are safe to introduce into codebase. If so, what is the process? Do they need to be FOSSed? | Integration testing should be carried out by a client of NCMP. Demo can be performed up the point NCMP produces message for the client. | ||||||||
14 | Can 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 synchronize and access I/O connections to the database. | No, It will compliment the design by adding an event loop for I/O synchronization and access. See: CPS-850 | ||||||||
15 | ONAP may be deprecating PLAINTEXT for Kafka. Strimzi Kafka might need to be used | No relevant information could be found relating to this. See: https://wiki.onap.org/display/DW/CPS-821+Spike%3A+Support+Async+read-write+operations+on+CPS-NCMP+interface#CPS821Spike:SupportAsyncreadwriteoperationsonCPSNCMPinterface-KafkaStrimziInvestigation | The underlying implementation won't be affected. The config will contain relevant configuration for protocol (e.g. PLAINTEXT, SASL) and connections. This information needs to be made configurable when implementing. | ||||||||
16 | Should we have something like the message count in the response or an indication of the last message at least.? | On the topic=Xyz async analysis, One item I forgot to mention was when a client might know when they have received the last response message for a request. If async there may be many responses (otherwise there's no need for async) Therefore should it not have something like the message count in it or an indication of the last message at least. | This is another step in an evolution of the product. Multiple response messages might become a necessity for asycnc bulk operations and maybe that is when we can discuss it in more detail. I don’t think it has to affect our current implementation additional field to handle that can always be added in a backward compatible way. | ||||||||
17 | Do we need Kafka messaging between DMI and NCMP? | This was discussed as it was argued that the client and CPS ecosystem is decoupled and async using only bus between ncmp and client. However, this would not rectify blocking calls between ncmp and dmi. | It was decided to have two separate kafka topics for client → ncmp & ncmp → dmi | ||||||||
18 | Can NCMP list all existing topics |
AC Point 3 : Topic does not exists (not allowed to create new topics, assuming NCMP can 'list' existing topics) Gareth Roper Need your suggestion. | |||||||||
19 |
Async: NCMP Rest impl. including Request ID generation | AC Points : 2. cm handle does not exists 3. No DMI registration for CM Handle | AC point 2 : We agreed to check only if cm handle exists. If cm does not exists will get Http status 404 as below. { AC point 3 . Is not valid. | ||||||||
20 | Client Kafka User & Privileges | After discussion with Fiachra Corcoran regarding Kafka-strimzi we will need to ensure client can access Kafka user and be allocated sufficient privileges (principle of least privilege) |
Proposed Design
...
draw.io Diagram | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...