Harmonise CD Events with CloudEvents

[thompson-tomo]

It would be great if CD Events could Harmonise their specifications with Cloud Events so that they are complementary and work together seamlessly without adapters.

My proposal would be as follows:

• All CD Events are wrapped in the cloud events envelope and values are what would be in CDEvent Context
• CDEvent Subject content is serialised into the data property of the cloud event envelope

I am aware that this is a significant breaking change but feel the ecosystem would benefit from this and enable CD events to focus on standardising the event definitions whole cloud events leads the way in how to pack and unpack the events.

This approach would also enable any cd events SDK to be simplified based on the fact that cloud events would be providing a class containing

• string representation of the data which needs to be de-serialised
• The name of the class the data needs to be Deserialised to

[afrittoli]

Hi @thompson-tomo - thank you for your interest in CDEvents and for your proposal.

CDEvents were designed with CloudEvents in mind, and are not in the business of describing how to pack and unpack the events. To reinforce this, a common request for CDEvents is verifiable events, and @xibz has been working with the CloudEvents community to implement that feature at the CloudEvents level directly.

Some design principles we followed when creating CDEvents:

• The CDEvents standard itself is independent from the underlying envelope/transport
• The CDEvents spec defines bindings that describe how a CDEvent is sent over a specific transport
• CloudEvents is the primary and preferred transport for CDEvents, as described in the CDEvents CloudEvents binding document. Fields in the CDEvents context were designed to be aligned with the CloudEvents specification as much as possible

CloudEvents supports two main modes:

• binary mode, where CloudEvents metadata is sent as HTTP headers and the payload and HTTP payload
• structured mode, where CloudEvents are all JSON sent over HTTP, with a section for CloudEvents metadata and a section for the payload. Structured mode enables batch sending of events.

CDEvents can be sent in either mode. The example in the binding doc uses binary mode, but structured mode could be used as well.

I would like to understand better what the issues you're facing are with the current spec, and what are the specific changes you're proposing. Perhaps an example of a rendered CloudEvent/CDEvents would help me understand what you mean better.

[thompson-tomo]

What I would be expecting is similar to the below for binary:

POST /sink HTTP/1.1
Host: cdevents.example.com
ce-specversion: 1.0
ce-type: dev.cdevents.taskrun.started.0.1.1
ce-time: 2018-04-05T17:31:00Z
ce-id: A234-1234-1234
ce-source: /staging/tekton/
ce-subject: /namespace/taskrun-123
Content-Type: application/json; charset=utf-8
Content-Length: nnnn

{
  "task": "my-task",
  "url": "/apis/tekton.dev/v1beta1/namespaces/default/taskruns/my-taskrun-123"
  "pipelineRun": {
    "id": "/somewherelse/pipelinerun-123",
    "source": "/staging/jenkins/"
  }
}

My concern is focussed on how the deserialisation can occur with the current approach and to enable us to optimise the data being transmitted.

What I think would help to improve the situation and provide a migration strategy.

• The definition of events focus on just the event payload and not the metadata
• one definition of event metadata is created
• one definition of a CD Event payload.
• the documentation describes how the event & metadata can be packed into a message.

The message packing could be:

• any of the 3 cloud events content modes with the data being as per above example
• cloud events Binary with the content type header to be set as application/CloudEvent+CDEvent so that the current payload can be used & migration is simply updating the content type header