Event Discovery and beyond

[Matthias Wessendorf]

Hi Knative community!

We have spent some time on thinking about improving the "Event Discovery" in Knative. For that a few things have been implemented already and were discussed in here.

However there is more!

In order to improve Event Discovery in Knative any further, this document highlights a number of proposals that are related and would together improve the UX for (secure) discovery of events for consumer functions.

The document discusses:

1. Generic Event discovery
2. Improved mapping of CloudEvent attributes and extensions
3. Event discovery for a given broker or channel
4. Event Policy
5. Knative Function integration
6. Backstage UI

Generic Event discovery in Knative Eventing

Unfortunately in Knative Eventing it is currently impossible to discover what types of events are consumable when there is no running workload.

We do however have an API, the EventType CRD, for these purpose, as described on the Website:

Knative Eventing defines an EventType object to make it easier for consumers to discover the types of events they can consume from Brokers or Channels

However this assumes that there are active workloads required to get the above described discovery. But in reality it is not possible today to tell what types of events are potentially_ available in Knative Eventing installation.

To address this huge drawback we have a Feature Track describing how the EventType API needs to change its behavior for a more generic discoverability.

Improved mapping of CloudEvent attributes and extensions

Creating a Trigger is best done when knowing the structure of the receiving event metadata, such as CloudEvent attributes and extensions, since those are supported on the filter(s) field(s) of the Trigger API.

The Knative Website says:

The event types stored in the registry contain all required information for a consumer to create a Trigger without resorting to some other out-of-band mechanism

However, this is not true. The EventType API is currently only representing three fields that map to the CloudEvent specification:

• type
• source URI
• schema URI

Therefore it is impossible using the EvenType API to discover all relevant information for creating a Trigger, which does support all CloudEvents attributes and extensions.

To address this we have a Feature Track that describes a better mapping of the EventType API and the CloudEvent specification.

Event discovery for a given broker or channel

The EventType API does give a good overview on what events are available in a given namespace for all brokers and channels. To filter this down to a specific broker or channel a complex query is needed in order to see which unique event types are available for a given addressable (e.g. broker or channel):

kubectl get eventtypes.eventing.knative.dev -o json | jq '.items[] | select(.spec.reference.name == "my-broker") | .spec.type' | sort | uniq

The command prints out a unique list of event types, for the given resource (here my-broker).

To address this we have a Feature Track that describes to provide a simplified view of EventType(s) for a given resource, like a Broker or a Channel, as part of the .status on the resource.

Event Policy

Currently there is also no way to restrict Brokers or Channels to a predefined list of allowed "event types". In combination with the discovery of event types, it is desired to introduce a (simple) policy for Brokers/Channels on who is sending what event.

There is no feature track for this problem, but an early GH issue is discussing this idea:

• knative/eventing#7256

Defining this policy is where we deliver on our own Vision statement where discovery and security meet

Knative Function integration

With a decent event discovery and the combination of kn commands and the kn func plugin, it is desired to simple have something like

kn func subscribe...

and we create a Trigger for the "function" that is being developed in the context. The subscribe command would offer an interactive prompt for selecting desired EventTypes and Brokers.

The new subscribe command is discussed in this Feature track

Backstage UI

For an improved UX it would be nice if EventTypes are visually available in a dedicated UI. It seems reasonable to provide some Knative upstream support for EventTypes and perhaps other entities, such as Brokers or Channels.

This feature is not required but nice to have. It would likely also attract a different set of contributors for the Knative upstream community as this is a good enhancement for the Knative ecosystem at large.

Onward!
Matthias