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
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 Possibly Common (base) set of headers but mandatory aspect might differ. In practice we might need a separate headers (schema?) for each event
4
Clarify the format of the version eventSchemaVersion
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.
We cannot override the mandatory/optional parameter from the Parent schema.
Toine Siebelink agrees to go ahead with separate schema/headers per event. There will be some duplication but it will have its advantage when versioning.
11
Is anyone using Async Request feature?
See
Jira Legacy
server
System Jira
serverId
4733707d-2057-3a0f-ae5e-4fd8aff50176
key
CPS-
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?
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!
Priyank Maheshwari confirmed headers can be described with a separate 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.
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) See decision on issue #7
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)
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?
kieran mccarthy this issue is now no longer relevant as the decision was to use CNCF Cloud Events instead as per decision #14
kieran mccarthyand Toine Siebelink agreed on general idea but exact list of common headers need to be agreed Jira (first impl.) to be added!
Jira Legacy
server
System Jira
serverId
4733707d-2057-3a0f-ae5e-4fd8aff50176
key
CPS-
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
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)
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 meetingkieran 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.
kieran mccarthyand Toine Siebelink agreed on general idea but exact list of common headers need to be agreed Jira (first impl.) to be added!
Jira Legacy
server
System Jira
serverId
4733707d-2057-3a0f-ae5e-4fd8aff50176
key
CPS-1717
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.
1717
15
During the meeting we saw that the Header fields were prefiXed with "ce_" so we need to check if we are ok with that.
assume "ce_" can be used as all user of the CNCF lib will get this behavior, will check if it can be replaced with no prefix at all. Sourabh Sourabh and Priyank Maheshwari concluded a cloud events specific serializer is used that add this prefix and cannot easily be changed (also that would be inconsistent use of this library)
CPS Team recommend to accept this prefix and simply document that this prefer is required when filtering on kafka headers defined by CloudEvenst standard.
team agreed with kieran mccarthy to accept "ce_" prefix on serialzied CE defined headers. Note. Event(s) documentation in RTD should mentioned this clearly too
16
Do will still need/ can we still use schemas for header details with CNCF library ?!
How to publish info about non-standard headers like correlationid ?
Meeting on Team agreed refer to CNFC doc. and add list of extensions in RTD documentation. (key and value constraints)
17
Inconsistent casing convention for header fields v. json data fields
Just observing. All header ion CNCF are lowercase whereas json field are camelCase. Don't want to change but want to make sure agree...
Confirm 'source'. is to be added to ALL events (declared mandatory for CNFC events)
kieran mccarthy confirm is is compulsory and a value will need to be set for all event definition. in NCMP a default value of 'ncmp' can be used if no other source is applicable. Toine Siebelink will update this page were needed to add this field and default value
The unique id identifying the event generated by DMI
X
Mandatory. Generated by DMI-Plugin
standard (id)
eventCorrelationId
string
The request id passed by NCMP
X
Mandatory. This is requestId that NCMP sent to client as an ACK. example : “request-1234" (UUID)
extension (correlationid)
eventTarget
string
The destination topic of the client
X
Mandatory. TBC example: my-topic
extension (destination)
source
string
The source of the event
Mandatory. example : dmi-plugin:enm-1 (dmi service name)
standard (source)
eventTime
string
The timestamp when original event occurred
X
Optional. The timestamp should follow that onhttps://www.rfc-editor.org/rfc/rfc3339#section-5. This follows ISO 8601 and is what is used/referenced in3GPP standards example: 1985-04-12T23:20:50.52Z this represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC.
standard (time)
eventType
string
The type of the event
X
Mandatory. NCMP owns eventType that would be used by dmi-plugins The Convention of eventType and Schema names is under discussion, see open issue #17 on CPS-1515 Spike
standard (type)
eventSchema
string
The event schema for async request response events
x
X
Mandatory. The Convention of eventType and Schema names is under discussion, see open issue #17 on CPS-1515 Spike
standard (dataschema)
eventSchemaVersion
string
The event schema version for async request response events
x
X
N/A included in 'dataschema'
event
Event
The payload of an event
xN/A
X
java object not yet defined by schema, see issue #2
No Properties defined (Entire event treated as single object)
CNCF Cloud Event alignment
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. )
The table below shows how previously proposed headers should be mapped to pre-defined CNFC headers.
Before
After1
CloudeEvent builder method
Example Value
Notes
eventId
(ce_)id
.withId()
Mandatory
eventSource
(ce_)source
.withSource()
Mandatory
N/A
(ce_)specversion (default 1.0)
.v1()
1.0
Mandatory - This is the version of the cloud events
eventType
(ce_)type
.withType()
Mandatory
eventTime
(ce_)time
.withTime()
Optional (could be Mandatory for
eventSchema
(ce_)dataschema
.withDataSchema()
Optional includes the version of the schema
content-type2
withDataContentType()
application/json
Optional
eventCorrelationId
(ce_)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 only applies to some events.
event
(ce_)data
.withData(json TBC)
Mandatory actual event/payload now would be under "data" field.
Note 1 all cloud-event headers will be prefixed during serialization with 'ce_' (this means when filtering on serialized Kafka-headers this prefix need to be applied)
Note 2 content-type is a a 'default' header name no 'wrapped' by CloudEvents and hence the inconsistency in names and that is does NOT have the 'ce_' prefix.
Common NCMP response staus code & message :
Status-code 0-99 is reserved for any success response
Status-code from 100 to 199 is reserved for any failed response.
Status Code
Status Message
0
Successfully applied changes
100
cm handle id(s) is(are) not found
101
cm handle id(s) is(are) in non ready state
102
dmi plugin service is not responding
103
dmi plugin service is not able to read resource data
