...
References
Jira Legacy server System ONAP Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 4733707d425b2b0a-2057557c-3a0f3c0c-ae5eb515-4fd8aff50176579789cceedb key CPS-1104 - CPS-858 Define Notifications on CM Handle Add (Ready) & Delete
...
| # | 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 wil 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'
|
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
...