| Warning |
|---|
WIP |
Jira item:
| Jira | ||||||
|---|---|---|---|---|---|---|
|
...
The purpose of this spike is to propose a strategy to ensure that CPS Data Updated event schema will be able to evolve with future requirements to come.
Compatibility Types
CPS supports one of the 3 following Several compatibility types between 2 consecutive event schema versionsexist when an event schema definition is evolving from one release to the next one:
Forward Compatibility
Forward compatibility type allows events produced by the new schema to be consumed by the previous schema.
...
- Deploy CPS Core new release (events form new schema are produced and still consumed as events from previous schema).
- Deploy CPS Temporal new release (event from new schema are produced and now consumed as events from new schema).
Changes
Schema
...
Versioning
Not having is own repository and being part of cps repository, cps-events Maven module is versioned each time cps repository is versioned. Then, having a cps-events Maven release does not means that the event schema is changed. It is possible that it is the exact same as the schema from previous cps-events release. Then, cps-events maven version can not be used to identify event schema version. Another versioning scheme is introduced to keep track of event schema versions. Following is the nomenclature for this versioning:
...
This version number is found in the Json event schema under the schema property.
Schema Property Type
In order for a given event instance to be produced by a previous event schema definition and read by a future event schema definition (backward compatibility), the schama schema version from the schema definition cannot be a constant anymore.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
{
"schema": "urn:cps:org.onap.cps:data-updated-event-schema:v1",
"id": "77b8f114-4562-4069-8234-6d059ff742ac",
... |
Consumer Ignores Type From Message Header
Event message header contains the type used by the producer when sending the message:
Header Key: __TypeId__
Header Value: org.onap.cps.event.model.CpsDataUpdatedEvent
In order to ensure that the listener would always be able to consume events produced with other future types, the consumer should not use this type id from the header to force the type to be used for reading.
Then following property is added to application properties:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
spring:
kafka:
consumer:
properties:
spring.json.use.type.headers: false |
The type to be used by the consumer is already provided in the existing 'spring.json.value.default.type' property.
Default Topic Name
A good practice of Event Driven Architecture is to avoid having multiple kind of events in the same topic. It means that the topic defined for Cps Data Updated Events should be dedicated to those events and is not supposed to receive any other kind of events. To reflect this intention, it is proposed to rename the default topic name with the name of the events that are published in the topic. Then, its name is changed from "cps.cps-cfg-state-events" to "cps.data-updated-events". This default name can still be changed by configuration using "CPS_CHANGE_EVENT_TOPIC" environment variable, if needed.
Gerrit Changes (WIP)
Conclusion
The minimal changes proposed above still give the option to make a forward compatible change in next coming release after Istanbul without introducing all the complexity coming with a complete solution right now, with the current design.
During Jakarta release the team would be able to consider other ways to implement event schema classes (currently automatically generated). Being able to rework the design of these classes could simplify the complete solution implementation for schema evolution if needed.
Note:
For future design work related to this subject, here is a Jackson reference to be looked at for event classes hierarchyReference note lo look at Jackson classes hierarchy for event classes: https://www.baeldung.com/jackson-inheritance