Determine pubsub encoding format for decoupling topic

[grantr]

If the data plane must be namespace-aware, the event format used in the pubsub messages may need to encode the namespace or other metadata along with the event.

We should version (separately from CloudEvents version) this internal format to allow for evolution.

[yolocs]

As we decided to adopt the shared broker data-plane, it becomes obvious that we need to attach additional info to each event, e.g. hostname, request path, etc. The current cloudevents pubsub binding doesn't allow us to do that easily (there is no interface to do that with the current sdk).

The current cloudevents binding logic:
With structured encoding - it directly writes the event bytes to the pubsub message.Data
With binary encoding - it writes standard cloudevent attributes to pubsub message.Attribute and data to message.Data

Some options I can think of:

Option 1:
Extend cloudevents pubsub binding to have additional function to "label" events. These functions won't be part of the common protocol interface. These "labels" will be set to pubsub message.Attributes with a special prefix (anything different from "ce-").

Option 2:
Develop a lib in knative-gcp for publish and pull pubsub message for gcp broker.
Publish: events -> convert to structured encoding -> set to message.Data and labels -> set to message.Attributes
Pull: the reverse of what's above.

[ericlem]

I'd tend to to favor something in the Option 1 case. We almost certainly don't want to be having to use structured encoding if possible. And 1 leaves the most fields still in interpretable form in pubsub without decoding.

[yolocs]

/assign @yolocs

[grantr]

We don't actually have to use structured encoding for option 2. Since we control both ends of the pubsub topics, we can use whatever encoding we want in pubsub messages, cloudevents compatible or not.

[yolocs]

Option 3:
WE can directly use cloudevents extension with a special prefix.

[grantr]

it becomes obvious that we need to attach additional info to each event, e.g. hostname, request path, etc

If we have a topic per broker, do we need any additional fields? Or are these fields only needed if we have a single shared topic for all brokers?

[yolocs]

I'm thinking a single shared topic. I thought we're going to have a single shared topic?

[grantr]

If single topic requires us to do additional work to partition the events, what is the advantage of that single topic? But I created #699 to discuss that.

I think I'm leaning toward option 3 (using extension attributes) since it seems like the least work for now. As has been pointed out by others, we can change this later if it proves to be an issue.

Would this be sufficient?

kngcpbv: "1"
kngcpns: "default"
kngcpn: "default"

[ericlem]

I'd agree with leaning towards 3

[liu-cong]

I prefer option 3 too. It seems to be what Extensions is designed for.