| Table of Contents |
|---|
Overview
...
| # | Description | Notes | Decision | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | No 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. | ||||||||||||||||
| 2 | Bulk Operation events details have not yet be defined (just headers) | Sourabh Sourabh to provide Jira tickets |
| ||||||||||||||||
| 3 | Should 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 | |||||||||||||||||
| 4 | Clarify the format of the version eventSchemaVersion |
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. | ||||||||||||||||
| 5 | What 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 | |||||||||||||||||
| 6 | Event(Content) field in DMI Async Request Response Event has inconsistent name (compared with other schemas) |
| CPS Team Create a V2 of the schema and rename eventContent as event. Do it as part of the schema addition. | ||||||||||||||||
| 7 | NCMP 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 (EST) 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:
| ||||||||||||||||
| 8 | Dmi 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. | ||||||||||||||||
| 9 | Can Kafka Headers be described with 'schema's owned and managed by NCMP | POC to follow.
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 .
| ||||||||||||||||
| 10 | Depending #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 :-
| 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. | ||||||||||||||||
| 11 | Is anyone using Async Request feature? | See
| 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) | ||||||||||||||||
| 12 | Do 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 | ||||||||||||||||
| 13 | AVC Subscription Event (DMI → NCMP) (events #3) |
| 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. | ||||||||||||||||
| 14 | Align headers with CNCF Cloud Events | Using 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
| ||||||||||||||||
| 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. |
...
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BatchResponseEvent Object
Type: Event (cps:org.onap.cps.ncmp.event.async:ncmp-async-batch-response-event-schema:v1)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
...
| Anchor | ||||
|---|---|---|---|---|
|
Cloudy Event Library
Introduction
CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.
- 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. )
...
Before | After | CloudeEvent builder method | Example Value | Notes |
|---|---|---|---|---|
eventId | id | .withId() | Mandatory | |
eventSource | source | .withSource() | Mandatory | |
N/A | specversion (default 1.0) | .v1() | 1.0 | Mandatory - This is the version of the cloud events |
eventType | type | .withType() | Mandatory | |
eventTime | time | .withTime() | Optional | |
eventSchema | dataschema | .withDataSchema() | Optional includes the version of the schema | |
| datacontenttype | withDataContentType() | application/json | Optional | |
| eventCorrelationId | correlationid | .withExtension() | Optional 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. | |
| event | data | .withData(json TBC) | Mandatory actual event/payload now would be under "data" field. |
...