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:
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.
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
URIschema
URITherefore 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.
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.
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:
Defining this policy is where we deliver on our own Vision statement where discovery and security meet
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
For an improved UX it would be nice if EventType
s are visually available in a dedicated UI. It seems reasonable to provide some Knative upstream support for EventType
s and perhaps other entities, such as Broker
s or Channel
s.
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