Versions Compared

Old Version 14

changes.mady.by.user Priyank Maheshwari

Saved on

compared with

New Version 15

changes.mady.by.user kieran mccarthy

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#Issue

Notes

Decisions

1Use "Generic" Detail-fields or or more specific fields

kieran mccarthy prefer to use specific terms like 'orginalState' instead of generic 'details'

2how many event schema's for different events will there be?

e.g. 1 schema for state change, 1 other schema for public properties?
OR
a single schema with some fields not always of the used/compulsory

Need to discuss with kieran mccarthy 

One single schema for all cmhandle LCM events : org.onap.ncmp:cmhandle-lcm-event:v1

3what is the best term to use for change events 'original', 'previous' or something elseTeam found term 'original' confusing and prefers 'previous' e.g. previousStateuse 'oldValues' and 'newValues'.  See analysis below.
4Should public properties be part of (same) structure as stateTeam 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.
5Should 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",   
”eventSchemaVersion”   : “v1.0",   

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'

    

6Mentioning the mandatory and optional fields in our schemas.

Mandatory(M) and Optional(O)

Schema Sample : 

Code Block
{
  "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.

[kieran]  This looks good - the given eventSource may change but the format is fine.

7Agree 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 ? 

Priyank Maheshwari There is no reason to separate cm data events from these lcm events.  They are all ncmp events and the consumer may determine the nature of the event from eventType/eventSchema.  Sugegst to send them on ncmp-events topic.

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

...