NOTE : This spike has been superseded by CPS-1104 Agree LCM Event schemas.
This should only be used as a reference and was used as input to CPS-1104.
References
CPS-858 - Getting issue details... STATUS
NOTE : This spike has been superseded by CPS-1104 Agree LCM Event schemas.
This should only be used as a reference and was used as input to CPS-1104.
Open Issues & Decisions
| # | Issue | Notes | Decision |
|---|---|---|---|
| 1 | should dataspaceName be given another name? | dataspaces are private to an application (e.g. NCMP) they should not be shared kieran mccarthy what do you mean by dataspaceName? | omit for now - put in later if needed/required. |
| 2 | should schema urn be generalized, how might it impact publication to ORAN R1? | The schema of the payload is dictated by the source of the event kieran mccarthy what do you refer to here? Ans : the schema refers to 'org.onap'. Emailed ORAN guys to identify how to close the gap between ORAN and ONAP. | Take this discussion separately. |
| 3 | should "ncmp" be used rather than "cps" in the type definitions | i.e. org.onap.cps.cmhandle-lcm-event or org.onap.ncmp.cmhandle-lcm-event? NCMP owns these events, 'cps' should not appear (even if cps is emitting them) NCMP java classnames begin with org.onap.cps.ncmp – Tony does not care kieran mccarthy , where does this type come from? | schema urn should refer to ncmp - not cps. |
| 4 | should a bulk cmhandle event be supported? | Prefer to delay this decision, but keep it in mind so we do not need to break compatibility to support it. -- Could be tricky as with horizontal scale NCMP, multiple will be emitting simulatneously | leave out of scope for now |
| 5 | should we consider the new state model changes on dmi-registry in the event as well? CPS-799 Spike: Define states and state handling for CM handle | For now we have cmhandle-state only in the event payload. But as per the spike(CPS-799) we have some information related to dataSyncState and datastore as well. Should we be extending this payload to add in more information or we will create a separate schema ? OR the schema suggested below is sufficient for the event listener. | Tony Finnerty kieran mccarthy Toine Siebelink we continue to go ahead with the agreed schema only. dataSyncState and datastore related info is anyways related to lifecycle state of cmHandle. |
| 6 | should we be introducing a correlationId inside the event payload? | There were few inputs from the team regarding adding a correlationId/cmHandleId inside the event payload itself (so that the event payload becomes self sufficient) and we can use the existing eventCorrelationId for event tracking and can also make it optional. Eg : { "cmHandleId" : "cmhandle-001" , | Tony Finnerty kieran mccarthy Toine Siebelink we will be keeping the eventCorrelationId and putting in cmHandleId based on the eventType , i.e if eventType is org.onap.ncmp.cmhandle-lcm-event then we populate cmHandleId , if not then we can have other id in there (it will be dependent on eventType? ) Also we will add the cmHandleId in the event payload. |
| 7 | We agreed to remove the operation field from the NcmpEvent Payload | Now that we agreed to publish the event based on cmHandle state change and not on operation , we will be removing the "operation" field from the event payload. Updated payload should look like this : Eg : { "cmHandleId" : "cmhandle-001" , | This is agreed and implemented as part of CPS-1100 - Getting issue details... STATUS |
| 8 | Introduce a "detail" section/field in the NcmpEvent Event section which can contain some details. | We discussed to introduce the detail section in one of our meetings which would contain the previous cmhandle state and some other details for the future. So my questions in regards to the detail section are as follows.
| This will be tracked as part of CPS-1104 - Getting issue details... STATUS |
| 9 | Where to track LCM event changes now that CPS-1104 is capturing the implementation details for cmhandle LCM schemas | This spike has been superseded by CPS-1104 Agree LCM Event schemas. This should only be used as a reference and was used as input to CPS-1104. Note CPS-1104 also proposed additional changes to the event body and the eventType. |
, but Toine does.Proposal
| Proposed event for cmhandle LCM |
|---|
{ |
Proposal Details
Scope covers the Create, Update and Delete of CM Handles.
Update is required as an application must know when we go from ADVISED to READY state.
cmhandle update event is ONLY sent for publicly available cmhandle metadata.
Changes to private cmhandle properties will not trigger a cmhandle LCM event.
| cmhandle Event Type | Detail | Event |
|---|---|---|
| CREATE | Add New CM Handle. # eventCorrelationId is used for the cmhandleId for "event" payload should include ALL public metadata for the cmhandle where appropriate. | { "cmHandleId" : "cmhandle-001", |
| UPDATE | Update cmhandle (e.g. a property update) # eventCorrelationId contains the updated cmhandleId modules / schemaSet is not sent in an org.onap.ncmp.cmhandle-lcm-event. Module upgrade will be addressed separately. Even if one public metadata property changes, ALL properties are sent in the update event. If the update cmhandle event was because of a removed/deleted cmhandle public property then that property is simply missing from the list of public cmhandle properties. | { "cmHandleId" : "cmhandle-001", |
| DELETE | Delete cmhandle # eventCorrelationId contains the deleted cmhandleId | { "eventId" : "00001", "eventCorrelationId : "cmhandle-001" "eventTime" : "2021-11-16T16:42:25-04:00", "eventSource" : "org.onap.ncmp", "eventType" : "org.onap.ncmp.cmhandle-lcm-event", ”eventSchema” : “org.onap.ncmp:cmhandle-lcm-event:v1", "event": { "cmHandleId" : "cmhandle-001" } } |
9 Comments
kieran mccarthy
Updated the CREATE and UPDATE to reflect that the create event is only sent when the state is READY
Priyank Maheshwari
Also I wanted to check if we have decided on the topic name to be used ?
If not I have few suggestions
or if we have some other preference ?
Toine Siebelink kieran mccarthy Tony Finnerty
kieran mccarthy
Hi Priyank Maheshwari
Perhaps just "ncmp-events" is enough? "broadcast" adds nothing of use to the name and "topic" adds nothing either as we know it is already a topic.
Would suggest to make the topic name be a configurable property on ncmp install if possible and not costly to implement.
That way, if an application using NCMP wishes to have their own topic naming patterns then the flexibility is built in. If no overriding value is given then "ncmp-events" topic name is used.
Best Regards
Kieran
Priyank Maheshwari
Hi Tony Finnerty kieran mccarthy
We had a meeting today and we discussed few items and few suggestions/points came up so I have listed the same in #5 and #6.
Let us know your thoughts on this.
Also I have made a small comment about the way cmhandle-properties are been represented in the json payload and how it will actually be.
Regards
Priyank Maheshwari
FYI : Toine Siebelink Bruno Sakoto Renu Kumari Aditya Puthuparambil Joseph Keenan
Tony Finnerty
You need to treat the header and the payload as separate entities.
The header is NCMP
The payload is sometimes NCMP, sometimes something else. In all cases the payload is structured by a published schema. That schema is referenced in the header (as I recall)
Priyank Maheshwari
Tony Finnerty kieran mccarthy Toine Siebelink
I have filled in the decision for #5 and #6.
Please correct me if I interpreted something incorrectly.
kieran mccarthy
This looks fine Priyank.
Toine Siebelink
perfect! I just added some colour
Priyank Maheshwari
Hi Tony Finnerty kieran mccarthy Toine Siebelink
I have added point #7 and #8.
#7 is just FYI. (have updated the examples to reflect the latest)
#8 is we discussed in one of the meetings. Just need few more inputs/clarifications.
Thanks