Versions Compared

Old Version 8

changes.mady.by.user kieran mccarthy

Saved on

compared with

New Version Current

changes.mady.by.user kieran mccarthy

Saved on

Key

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

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

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCPS-858


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

Alt #1 :  { "eventId": "00001", "eventTime": "2015
#IssueNotesDecision
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.
2should 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'. 
Not sure if this is acceptable in an ORAN R1 specification.

Emailed ORAN guys to identify how to close the gap between ORAN and ONAP.
Not clear if we can publish an onap schema in ORAN!  Waiting on response.

Take this discussion separately.
Approach would be to define it in ORAN community first and then come to ONAP to support ORAN schemas

3should "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 (smile), but Toine does.

kieran mccarthy , where does this type come from?

schema urn should refer to ncmp - not cps.
4should 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

Input Reference Material

RFC 8639 : Subscription to YANG Notifications

Alternatives 

Alternative event headers include

Alt #1 

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.

6should 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 : 

{
  "eventId"                   : "uuid",        
  "eventCorrelationId  : "random-uuid",      // this can be optional
  "eventTime"              : "2021-11-16T16:42:25-04:00",

"eventType":


  "eventSource"           : "org.onap.ncmp

.CmHandleCreateEvent

",                                 

  "eventType" 

 

 

"eventSource": "org.onap.ncmp", # ??? Is this needed?

 

 

 

"event": {
<event body>
}Alt #2 Based on current CPS event{

 

"schema"

: "org.onap.ncmp

:

.cmhandle-lcm-event

-schema:v1

",   

  "id": "77b8f114-4562-4069-8234-6d059ff742ac",
  "source": "org

  ”eventSchema”         : “org.onap.ncmp

",
  "type"

:

"org.onap.ncmp.

cmhandle-lcm-event:v1",   

  "

content

event": {

     "

observedTimestamp"

cmHandleId"           : "

2020-12-01T00:00:00.000+0000",  # time of received REST registration request
     "cmhandleId": "43t345tbnfd85435"
     "operation" : "CREATE",
     "data" : {

           <event body>

      }

}

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.

Proposal is via the main scenarios.... the schema can reflect this.

cmhandle Event TypeDetailEventCREATEAdd New CM Handle.
CM Handle added to NCMP in ADVISED state with publicCmhandleProperties{
  "schema": "org.onap.ncmp:cmhandle-lcm-event-schema:v1",
  "id": "77b8f114-4562-4069-8234-6d059ff742ac",
  "source"

cmhandle-001" ,
     “operation”               : “create”,
     “cmhandle-state”      : “READY”
     “cmhandle-properties” : [
          “public-property-name-1” : “public-property-value-1”,
          “public-property-name-2” : “public-property-value-2”     ]
    }
}


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.

7We 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 : 

{
  "eventId"                   : "uuid",        
  "eventCorrelationId  : "random-uuid",      // this can be optional
  "eventTime"              : "2021-11-16T16:42:25-04:00",
  "eventSource"           : "org.onap.ncmp",                                 
  "

type"

eventType"              : "org.onap.ncmp.cmhandle-lcm-event",   
  ”eventSchema”   

"content": {

     

"observedTimestamp": "2020-12-01T00:00:00.000+0000",  # time of received REST registration request
     "cmhandleId": "43t345tbnfd85435"

: “org.onap.ncmp:cmhandle-lcm-event:v1",   

  "event": {

     "

operation"

cmHandleId"           : "

CREATE

cmhandle-001" ,
      “cmhandle-state”     

"data"

:

{   # May add new payload info in future, e.g.  publicCmHandleProperties
         "state" : {
              "cmhandleState" : "ADVISED"
           }
    }
  }
}UPDATE

Update cmhandle.
cmhandle goes from ADVISED to READY once the schemas are
discovered/added for the cmhandle

schemaSet is also sent in the event as it has been updated along
with the state transition

{
  "schema": "urn:cps:org.onap.ncmp:cmhandle-lcm-event-schema:v1",
  "id": "77b8f114-4562-4069-8234-6d059ff742ac",
  "source": "urn:cps:

“READY”
     “cmhandle-properties” : [
          “public-property-name-1” : “public-property-value-1”,
          “public-property-name-2” : “public-property-value-2”     ]
    }
}


This is agreed and implemented as part of

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCPS-1100

8Introduce 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.

  1. detail section would be a free-text (String) and can contain multiple concatenated values?
  2. if #1 is not true , then it needs to be structured ? if yes then what will be the structure ?
  3. if #1 and #2 are not required then do we add the "last-cmhandle-state" as a new field in the event payload ? 

This will be tracked as part of

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCPS-1104

9Where 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.

Proposal

 Proposed event for cmhandle LCM

{
  "eventId"                   : "00001",        
  "eventCorrelationId  : "cmhandle-001",      
  "eventTime"              : "2021-11-16T16:42:25-04:00",
  "eventSource"           : "org.onap.ncmp",                                 
  "

type"

eventType"              : "org.onap.

cps

ncmp.cmhandle-lcm-event",   

  "content": {
    "observedTimestamp": "2020-12-01T00:00:00.000+0000",
    "cmhandleId": 43t345tbnfd85435
    "operation" : "UPDATE",
    "data": {  #  only changed properties are returned
         "state" : {
             "cmhandleState" : "READY"
          },
         "schemaSet": ["schema-name-1", "schema-name-2", "schema-name-3", "schema-name-4", "schema-name-5"]   #  list of all yang modules
      }
    }
  }
}UPDATE

Update cmhandle

Multiple updates to a cmhandle
Update a publicCmhandleProperty attributes

{
  "schema": "urn:cps:org.onap.ncmp:cmhandle-lcm-event-schema:v2",
  "id": "77b8f114-4562-4069-8234-6d059ff742ac",
  "source": "urn:cps:

  ”eventSchema”         : “org.onap.ncmp:cmhandle-lcm-event:v1",   

  "event": {
     “operation”               : “create”,
     “cmhandle-state”      : “ADVISED”
     “cmhandle-properties” : [
          “public-property-name-1” : “public-property-value-1”,
          “public-property-name-2” : “public-property-value-2”     ]
    }
}

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 TypeDetailEvent
CREATE

Add New CM Handle.
CM Handle added to NCMP with publicCmhandleProperties and is in READY state 


# eventCorrelationId is used for the cmhandleId for 
org.onap.ncmp.cmhandle-lcm-event

"event" payload should include ALL public metadata for the cmhandle where appropriate.

{
  "eventId"                  : "00001",    
  "eventCorrelationId  : "cmhandle-001",       
  "eventTime"              : "2021-11-16T16:42:25-04:00",
  "eventSource"           : "org.onap.ncmp",                                 
  "

type"

eventType"              : "org.onap.

cps

ncmp.cmhandle-lcm-event",   

  "content": {
    "observedTimestamp": "2020-12-01T00:00:00.000+0000",
    "cmhandleId": 43t345tbnfd85435
    "operation" : "UPDATE",
    "data": {
         "publicCmhandleProperties" : [
             "property-name-1" : null   #  indicates the property has been deleted/removed from the cmhandle

  ”eventSchema”         : “org.onap.ncmp:cmhandle-lcm-event:v1",   

  "event": {
     “cmhandle-state”     : “READY”,

      "cmHandleId" : "cmhandle-001",
     “cmhandle-properties” : [
         

   "

{“public-property-name-

2"

1” :

"some

“public-

prop

property-value-

2"  # indicates the property has been modified.

1”},
         

   "

{“public-property-name-

3"

2” :

"some

“public-

prop

property-value-

3"  # This is a new cmhandle property added.

2”}     

   ]


     

}

 

  }

]

 

    }
}

UPGRADE
UPDATE

Upgrade cmhandle

SchemaSet change.  
Triggered by an upgrade of a network element for example

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.

{
  "

schema": "urn:cps:org.onap.ncmp:cmhandle-lcm-event-schema:v2",
  "id": "77b8f114-4562-4069-8234-6d059ff742ac

eventId"                  : "00001",    
  "eventCorrelationId  : "cmhandle-001"      
  "eventTime"              : "2021-11-16T16:42:25-04:00",
  "

source"

eventSource"           : "

urn:cps:

org.onap.ncmp",                                 
  "

type"

eventType"              : "org.onap.

cps

ncmp.cmhandle-lcm-event",   

  "content": {
    "observedTimestamp": "2020-12-01T00:00:00.000+0000",
    "cmhandleId": 43t345tbnfd85435
    "operation" : "UPGRADE",
    "data": {

  ”eventSchema”         : “org.onap.ncmp:cmhandle-lcm-event:v1",   

  "event": {
     “cmhandle-state”     : “READY”,

     "cmHandleId" : "cmhandle-001",
     “cmhandle-properties” : [
         

"originalSchemaSet" : ["schema-name-1", "schema-name-2", "schema-name-3", "schema-name-4", "schema-name-5.1"],

{“public-property-name-1” : “public-property-value-1”},
         

"newSchemaSet": ["schema-name-1", "schema

{“public-property-name-

2", "schema-name-3", "schema-name-4", "schema-name-5.2", "schema-name-6"]
      }
    }
 

2” : “public-property-value-2”}     
       ]
    }
}

DELETE

Delete cmhandle

# eventCorrelationId contains the deleted cmhandleId

{
  "
schema": "org.onap.ncmp:cmhandle-lcm-event-schema:v1",
  "id": "77b8f114-4562-4069-8234-6d059ff742ac
eventId"                  : "00001",    
  "eventCorrelationId  : "cmhandle-001"      
  "eventTime"              : "2021-11-16T16:42:25-04:00",
  "
source"
eventSource"           : "org.onap.ncmp",                                 
  "
type"
eventType"              : "org.onap.ncmp.cmhandle-lcm-event",   
  "content": {
    "observedTimestamp": "2020-12-01T00:00:00.000+0000",
    "cmhandleId": 43t345tbnfd85435
    "operation" : "DELETE"
  ”eventSchema”         : “org.onap.ncmp:cmhandle-lcm-event:v1",   

  "event": {
     "cmHandleId" : "cmhandle-001"
    }
}