References
- CPS-1104 - Getting issue details... STATUS
- CPS-858 Define Notifications on CM Handle Add (Ready) & Delete
Issues & Decisions
| # | Issue | Notes | Decisions |
|---|---|---|---|
| 1 | Use "Generic" Detail-fields or or more specific fields | kieran mccarthy prefer to use specific terms like 'orginalState' instead of generic 'details' | |
| 2 | how many event schema's for different events will there be? | e.g. 1 schema for state change, 1 other schema for public properties? | Need to discuss with kieran mccarthy One single schema for all cmhandle LCM events : org.onap.ncmp:cmhandle-lcm-event:v1 |
| 3 | what is the best term to use for change events 'original', 'previous' or something else | Team found term 'original' confusing and prefers 'previous' e.g. previousState | use 'oldValues' and 'newValues'. See analysis below. |
| 4 | Should public properties be part of (same) structure as state | Team feels state and properties are very different and should not be combined into same structure This also depends on open issue #2 | Agreed at team meeting that all cmhandle metadata attributes to be managed in the same manner whether that is state or properties. |
| 5 | Should the schema version be separate from 'eventSchema'? | The event schema is defined like this : org.onap.ncmp:cmhandle-lcm-event:v1 where version is at the end of the schema string. It would be better to split the schema version into its own header field. e.g. ”eventSchema” : “org.onap.ncmp:cmhandle-lcm-event", | Toine Siebelink Can we split the schema version into its own field or is it a standard way to reference schema versions like the way CPS do it for their events (at least I think this is what they do?) like this : 'org.onap.ncmp:cmhandle-lcm-event:v1'
|
| 6 | Mentioning the mandatory and optional fields in our schemas. | Mandatory(M) and Optional(O) Schema Sample : {
"eventId" : "00001", (M)
"eventCorrelationId : "cmhandle-001" (M)
"eventTime" : "2021-11-16T16:42:25-04:00", (M)
"eventSource" : "org.onap.ncmp", (M)
"eventType" : "org.onap.ncmp.cmhandle-lcm-event.create", (M)
”eventSchema” : “org.onap.ncmp:cmhandle-lcm-event:v1", (M)
"event": {
“cmhandleId” : “cmhandle-id-001”,(M)
"newValues" : { (O)
“cmhandle-state” : “READY”, (O)
“dataSyncEnabled” : “TRUE”, (O)
“cmhandleProperties” : [ (O)
“someProperty-1” : “Initial property value 1”, (O)
“someProperty-2” : “Initial property value 2” (O)
]
}
}
}
| kieran mccarthy Please correct if something is wrong. |
| 7 | Agree on the topic name where the events need to be published. | Previously we configured the topic name as "ncmp-events" , but since now we are calling these events as LcmEvents , I was wondering if the topic should reflect the same. Toine Siebelink suggested "ncmp-lcm-events" as an alternative name. | kieran mccarthy Tony Finnerty your thoughts on this ? |
Overview
This page is for deciding the structure of the proposed "detail" section which needs to be introduced in the NcmpEvent payload.
Refer : CPS-858 Define Notifications on CM Handle Add (Ready) & Delete #8
Purpose : Additional field(s) to store information about the previous state.
Current Schema
Proposed events