Versions Compared

Key

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

...

Agree exact list of comment headers. 
  • Is there a separate field for datacontenttypeversion or is it part of datacontenttype ?
  • During kafka
  • Also we need to look at the filtering strategy to filter the records by reading the headers only.
  • #DescriptionNotesDecision
    1No Event properties defined for DMI AVC Event

    Priyank Maheshwari will need to specify  and agreed event structure for DMI AVC Event with stakeholders  ie. provide Jira ticket


    Event Body should be compatible with RFC8641

    kieran mccarthy has confirmed.

    Priyank Maheshwari created JIRA to create the event body schema. 

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyCPS-1668

    2Bulk Operation events details have not yet be defined (just headers)

    Sourabh Sourabh to provide Jira tickets

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyCPS-1658

    3Should all the events have same kafka headers

    kieran mccarthy Posissbly Common (base) set of headers but mandatory aspect might differ. In practice we might need a separate headers (shema?) for each event

    4Clarify the format of the version eventSchemaVersion

    v1 or 1.0

    EX: 1.0.0 (without 'v')

    kieran mccarthy to check ORAN preference

    kieran mccarthy confirms through email on to use semantic versioning which ORAN follows https://semver.org.

    5What to do with additional event headers (from DMI Plugins)

    kieran mccarthy   if DMI produce Additional headers NCMP will discard those ie. not included in forwarded events

    6Event(Content) field in DMI Async Request Response Event has inconsistent name (compared with other schemas)
    1. Add V2 file
    2. Deprecate V1
    3. Support both versions for a while
    4. Delete the V1 version (after some time )

    CPS Team  Create a V2 of the schema and rename eventContent as event. Do it as part of the schema addition.

    7NCMP Async Request Response Event (#5) contains both an Event and ForwardedEvent

    ForwardedEvent is not wrapped inside Event but question now is if we need 2 events at all?!

    Sourabh Sourabh  and Raviteja Karumuri  can check how it is actually working and then we decide ( create a JIRA ticket )

    Wiki for the Study on NCMPAsyncRequestResponse event schema

    Conclusion: events not designed as proposed, very inconsistent. Never go a bug because these async events aren't used at all (confirmed by Csaba Koscis) Instead bulk request wil be used for topology use cases.

    kieran mccarthy and team agreed to:

    1. Temporary disable the legacy async request feature (task created: 
      Jira
      serverONAP Jira
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keyCPS-1694
      )
    2. Aas part of a lower priority work items (but during Montreal) fix related events with learnings from the new batch-usecase. (task created
      Jira
      serverONAP Jira
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keyCPS-1693
      )
    8Dmi Data AVC Event, use of eventSource field

    Priyank Maheshwari wanted to store 'datastore' in this field but kieran mccarthy explained it to use for different purposes

    kieran mccarthy Clients can use this field as per their requirements. 

    9Can Kafka Headers be described with 'schema's owned and managed by NCMP 

    POC to follow. 

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyCPS-1657

    Defining header schema.

    Integration of header with kafka.

    Naming and versioning convention for the header schemas. 'id' 

    Does the headers schema have a version too?!


     Priyank Maheshwari confirmed headers can be described with a separate schema.

    Both header schema's and event schemas wil be published on https://docs.onap.org/projects/onap-cps/en/latest/cps-events.html

    Header schema name and version will be maintained in the 'id' metadata field of header's schema . 

    Defined Common Header schema. Extended it and used in a base class

    10Depending #10 can schema inherit/extend a common schema for common headers

    Commonly define them and then define what are mandatory(required) or optional as per the schema extending it.

    If a field is not used in the extended schema then it should be able to handle it.

    Extend the POC ( on #9 ) to cover this.

     Priyank Maheshwari did the POC and the conclusion of that was that :-

    • One schema can extend the other schema.
    • We cannot override the mandatory/optional parameter from the Parent schema. 

     PoC ongoing

    Toine Siebelink agrees to go ahead with separate schema/header per event.  There will be some duplication but it will have its advantage when versioning. 

    11Is anyone using Async Request feature?

    See

    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyCPS-1660
    we need to re-design event  #4 (Covers Point 6 as well) and #5 in a backward incompatible way. If no-one is using this feature right now (suspected) we can do this more easily/cheaper!

     Csaba Kocsis confirmed this is not used by Ericsson currently. No plans to use soon for single-cmhandle requests either (TBC). Need to decide priority (Csaba Kocsis to find out of fixing the legacy schema(s)
    See decision on issue #7

    12Do we need additionalProperties for DMI ASync Data Request respondes (events #4, #5)The original code populates a framework defined 'additionalProperties' field with a singel key-value pair: "response-data",{<json data>}. No other (private) properties are added either in DMI PLugin or NCMP code. The name is just coincidence and misleading. In fact this 'additionalProperties' field should NOT have been used at all!No, the new schema should NOT add  'additionalProperties' field at all use 'additionalProperties:no' in the schema
    13AVC Subscription Event (DMI → NCMP) (events #3)
    • Want to understand what 'data' is datatype referring to under Subscription Event?
      • What value comes under 'schemaName' & 'SchemaVersion' of Datatype definition under AVC Subscription Event?
      • Reconfirmation needed on 'schemaName' & 'SchemaVersion'  should be in the payload?

    In meeting kieran mccarthy updated #3 is ON HOLD to analyse further. 

    Agreed with Toine Siebelink  on that Priyank Maheshwari  will look into this from now as they are working on something related to this.

    14Align headers with CNFC Cloud EventsUsing standard headers as defined by Cloud Events and possibly common header extension See Table below, CNFC Cloud Event alignment
    CPS will use Cloud Events  3PP for all current and legacy events to ensure common format

    kieran mccarthyand Toine Siebelink  agreed on general idea but exact list of common headers need to be agreed 
    Jira (first impl.) to be added!

    15

    During

    the meeting we saw that the

    Kafka header fields were prefixed with "ce_ " so need to check if we are ok with that.

    kieran mccarthyand Toine Siebelink  agreed on general idea but exact list of common headers need to be agreed 



    Event Overview

    #Short NameSourceDestinationImpl. StatusNotesFull Schema NameDiagram Ref.
    1LCM EventNCMPClient AppsIn UseLife Cycle Management Events, when cmHandles are added or removedcps:org.onap.ncmp.cmhandle.lcm-event:v1CM-Handle State Changes and Notifications Overview#Notificationhandlingincode
    2DMI Data AVC EventDMINCMPImplemented, Not in useAttribute Value Change in configuration management (CM) data.cps:org.onap.cps.ncmp.events:avc-event-schema:v15 in CPS Data Notifications Overview#ComponentDiagram
    3AVC Subscription Create EventClient NCMP & DMIsImplemented, Not in useCreate Event Only

    cps:org.onap.cps.ncmp.events:avc-subscription-event:v1

    7 in CPS Data Notifications Overview#ComponentDiagram
    4DMI Async Request Response EventDMINCMPIn UseDMI passes response onto Kafka topic specified by client.

    cps:org.onap.cps.ncmp.events:dmi-async-request-response-event-schema:v1

    3b → 4a in CPS-821 Spike: Support Async read-write operations on CPS-NCMP interface#ProposedDesign
    5NCMP Async Request Response EventNCMPClient AppsIn UseForward No.4 to client specified topic

    cps:org.onap.cps.ncmp.events:ncmp-async-request-response-event-schema:v1

    4b → 5 in CPS-821 Spike: Support Async read-write operations on CPS-NCMP interface#ProposedDesign
    6Bulk Response Event (Internal)DMINCMPIn ProgressInternal Kafka topiccps:org.onap.cps.ncmp.event:dmi-async-bulk-response-event-schema:v15 in CPS-1515: Spike: Support Multiple CM-Handles for NCMP Get Operation (batch operations)
    7

    Bulk Response Event (Client)

    NCMP Client AppsIn ProgressForwarding the DMI responses to the client topiccps:org.onap.cps.ncmp.event:ncmp-async-bulk-response-event-schema:v16 in CPS-1515: Spike: Support Multiple CM-Handles for NCMP Get Operation (batch operations)

    ...

    CNCF Cloud Event alignment

    Cloudy Event Library

    Introduction....

    • These cloud events will be applied to all the internal and external events we have in CPS , NCMP and DMI Plugin.
    • Cloud events will be taking care of the fields which are part of kafka headers or part of the actual payload ( fields other than "data" are sent as kafka headers )
    • These CNCF cloud events will be applied to all the events listed in above sections ( LCM , DMI Data AVC etc. )

    link to library 

    link to online example


    M  ( M ) ( M )( M ) ( O )datacontenttype 
    ( O )( O ) eg :

    Before

    After

    CloudeEvent builder methodExample ValueNotes

    Before

    After

    Notes

    eventId

    id

    .withId()
    Mandatory

    eventSource

    source



    Mandatory

    N/A

    specversion  (default 1.0)


    1.0Mandatory  - This is the version of the cloud events

    eventType

    type



    Mandatory

    eventTime

    time



    Optional

    eventSchema

    dataschema



    Optional  includes the version of the schema


    datacontenttype
    application/json
    eventdata( M ) actual event/payload now would be under "data" field.
    Optional
    eventCorrelationIdcorrelationid.withExtension

    ( O ) This will be part of the extensions field in the cloud events and all the restrictions of the attribute field naming applies to it.

    i.e these fields will be in the small case.

    This is marked as optional as it applies to the event which has this field.

    ...

    eventdata.withData(json TBC)
    ( M ) actual event/payload now would be under "data" field.

    ...