Discovery of Events in the broker/channel status

[matzew]

Feature Track document: https://docs.google.com/document/d/1vN-xd6yuTFVCgXrMSJVjHK-0U1yuXy_KIAf1Zfn2vjk/edit

Problem

The events processed by a broker/channel can be monitored by looking what event type is available, for a given broker/channel.

For instance, take this list of event types:

k get eventtypes.eventing.knative.dev 
NAME                                              TYPE        SOURCE              SCHEMA   REFERENCE NAME   REFERENCE KIND    DESCRIPTION                             READY   REASON
et-my-broker-68c23082bef5cc5a5650b2a4164581e1     foo.bar     my/fancy/command/            my-broker        Broker            Event Type auto-created by controller   True    
et-my-broker-b8067eff8a782a7560c3136744d077b3     fooz.barz   my/curl/command              my-broker        Broker            Event Type auto-created by controller   True    
et-my-broker-dc90e945469d1db5a57c95d98ebb380f     foo.bar     my/curl/command              my-broker        Broker            Event Type auto-created by controller   True    
et-testchannel-c44c6680141ffe5498059f8a0bfd6bfa   foo.bar     my/curl/command              testchannel      InMemoryChannel   Event Type auto-created by controller   True    

In this example we can see that the my-broker has the following events:

• foo.bar
• fooz.barz
• foo.bar

We can also just filter the results by just asking for the value of the type, for the my-broker, like:

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

"foo.bar"
"fooz.barz"
"foo.bar"

but that is quiet a complex query. However this still contains duplicate event types, coming from different source URIs.

Adding a few more tools, you get a deduplicated list:

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

"foo.bar"
"fooz.barz"

Event list via Broker/Channel status

It would be nice if that information would be part of the status, instead of performing such a "query'.

For instance:

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: my-broker
# ...
status:
  events:
  - "fooz.barz"
  - "foo.bar"

The events on the status would be a basically a simplified view, for a specific broker/channel, of its referenced EventType objects. However we would need to deduplicate event types, to avoid that this status list has n "ping events", b/c we have "n" ping sources pointing to the broker/channel.

RBAC

Another benefit is that the status subresource allows a more finegrain access control, so we can allow 3rd parties to just query the event types of a given broker/channel. Little POC by @aliok done: https://gist.github.com/aliok/aeffa1f9da09e2b794b771ac7c888266

Persona: developers

Exit Criteria A measurable (binary) test that would indicate that the problem has been resolved.

[Cali0707]

@matzew I really like this idea! One thing which I think might make it even more powerful is a view of "live" vs. "static" eventtypes on the broker. What I'm thinking is that if we know that a specific source is emitting eventtypes to a broker, then we know that those eventtypes "exist" at the broker, at least in a static sense. However, if one of those events actually arrives at the broker then we know that that eventtype is "live" in the system.

I think we could display this with a slight modification to your example:

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: my-broker
# ...
status:
  events:
    - name: "fooz.barz"
      live: true
    - name: "boo.bar"
      live: false

WDYT?

[matzew]

That would imply some TTL of the event as well as there is potential race when a number of "data plane receivers" (ingress) are updating the status of the one broker. Therefore I am not really sure if that's worth for doing right now.

We can always add that, but I'd want to start w/o that extra data and issues now

[Cali0707]

With eventtype autocreate potentially making a LOT of eventtypes, and there being a cap on k8s object size (I think 1.5MiB is the max request etcd supports) is it worth putting some kind of cap on how many eventtypes we set in the status of a broker/channel, or maybe some kind of garbage collection of older autocreated eventtypes from the status?