Event consumers should not need knowledge of how events get routed

[bbrowning]

This is the consumer side of #814

When consuming events from Knative Eventing today, those events are consumed from a Channel by creating a Subscription. An example:

apiVersion: eventing.knative.dev/v1alpha1
kind: Subscription
metadata:
  name: cronjob-source-sample
spec:
  channel:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Channel
    name: testchannel
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: message-dumper

This requires making a decision every time a subscription - what Channel should this consume events from and do I need to create that Channel?

What's lacking is a way to consume events from Knative Eventing without having to make a decision about how that event was produced or routed. Instead, I'd like to consume events from based on the CloudEvents attributes or body of that event - source, type, fields within the body, etc.

Something like this:

apiVersion: eventing.knative.dev/v1alpha1
kind: Subscription
metadata:
  name: cronjob-source-sample
spec:
  filter:
    type: 'dev.knative.cronjob.event'
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: message-dumper

Or, if we have some concept of a well-known and statically named event Bucket (naming TBD, also referred to as Broker or Router) then something like:

apiVersion: eventing.knative.dev/v1alpha1
kind: Subscription
metadata:
  name: cronjob-source-sample
spec:
  bucket:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Bucket
    name: default
  filter:
    type: 'dev.knative.cronjob.event'
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: message-dumper

See Knative Eventing use cases and product requirements - 2019 and Broker and Trigger for some prior discussion and ideas around these topics. Those docs should be visible to anyone in the knative-users Google Group.

[bbrowning]

While working through the consumption example, I realized that we're missing some metadata when producing events for things like CronJob. If events aren't tied to a specific Channel, then there's no easy way to distinguish one kind of CronJob event from another. They all have the same CloudEvents source attribute of CronJob and type of dev.knative.cronjob.event. So, by removing Channel as a requirement for producing/consuming events, we'll need to enrich the metadata with other filterable attributes.

[evankanderson]

We should probably append metadata.namespace and metadata.name to the source attribute, though that ties the producer and consumer more closely than we would normally want.

[bbrowning]

That would be one option. Or, we may want to have some additional optional attributes that Knative Sources add to the CloudEvent. I'm not sure of the extension mechanism there, but we have several pieces of metadata - namespace and name, perhaps others - that may be generally useful to have inside the events.

[evankanderson]

/area ux-decision

[bbrowning]

Having channel and bucket keys feels awkward, when the values of each key are really just an object reference. So, if we're going to add a new key, I'd actually prefer perhaps from that can take either a Channel or a Bucket.

Example from a Channel:

apiVersion: eventing.knative.dev/v1alpha1
kind: Subscription
metadata:
  name: cronjob-source-sample
spec:
  from:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Channel
    name: testchannel
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: message-dumper

Example from a Bucket:

apiVersion: eventing.knative.dev/v1alpha1
kind: Subscription
metadata:
  name: cronjob-source-sample
spec:
  from:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Bucket
    name: default
  filter:
    type: 'dev.knative.cronjob.event'
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: message-dumper

This may imply creating a new interface that represents the opposite thing as Addressable.

Related is the question of whether a Subscription should be allowed to specify a filter for both Channel and Bucket. On the surface that seems reasonable, but one of the design decisions around Channel was that it was a simple point-to-point pipe. If a Channel should not allow filtering but a Bucket should, then Channel and Bucket may not actually share a common interface and thus we may end up with two separate keys here after all.

[vaikas]

@bbrowning closing as this has been fixed, reopen if you don't feel so.