Event registry

    Before you begin

    1. Read about the and trigger objects.
    2. Be familiar with the , particularly the Context Attributes section.
    3. Be familiar with .

    Using the registry, you can discover different types of events that can be consumed by broker event meshes. The registry is designed for use with the broker and trigger model, and aims to help you create triggers.

    To see event types in the registry that are available to subscribe to, enter the following command:

    Below, we show an example output of executing the above command using the namespace in a testing cluster. We will address the question of how this registry was populated in a later section.

    1. NAME                                         TYPE                                    SOURCE                                                               SCHEMA        BROKER     DESCRIPTION     READY     REASON
    2. dev.knative.source.github.push-34cnb         dev.knative.source.github.push          https://github.com/knative/eventing                                                default                    True
    3. dev.knative.source.github.push-44svn         dev.knative.source.github.push          https://github.com/knative/serving                                                 default                    True
    4. dev.knative.source.github.pullrequest-86jhv  dev.knative.source.github.pull_request  https://github.com/knative/eventing                                                default                    True
    5. dev.knative.source.github.pullrequest-97shf  dev.knative.source.github.pull_request  https://github.com/knative/serving                                                 default                    True
    6. dev.knative.kafka.event-cjvcr                dev.knative.kafka.event                 /apis/v1/namespaces/default/kafkasources/kafka-sample#news                         default                    True
    7. dev.knative.kafka.event-tdt48                dev.knative.kafka.event                 /apis/v1/namespaces/default/kafkasources/kafka-sample#knative-demo                 default                    True
    8. google.pubsub.topic.publish-hrxhh            google.pubsub.topic.publish             //pubsub.googleapis.com/knative/topics/testing                                     dev                        False     BrokerIsNotReady

    NOTE: This assumes that the event sources emitting the events reference a broker as their sink.

    There are seven different EventType objects in the registry of the default namespace.

    Use the following command to see an example of what the YAML for an EventType object looks like:

    1. kubectl get eventtype dev.knative.source.github.push-34cnb -o yaml

    Omitting irrelevant fields:

    From a consumer standpoint, the fields that matter the most are the spec fields as well as the status.

    Regarding status, its main purpose it to tell consumers (or cluster operators) whether the EventType is ready for consumption or not. That readiness is based on the Broker being ready. We can see from the example output that the PubSub EventType is not ready, as its dev Broker isn’t.

    Let’s talk in more details about the spec fields:

    • type: is authoritative. This refers to the CloudEvent type as it enters into the event mesh. It is mandatory. Event consumers can (and in most cases would) create Triggers filtering on this attribute.

    • source: refers to the CloudEvent source as it enters into the event mesh. It is mandatory. Event consumers can (and in most cases would) create Triggers filtering on this attribute.

    • schema: is a valid URI with the EventType schema. It may be a JSON schema, a protobuf schema, etc. It is optional.

    • description: is a string describing what the EventType is about. It is optional.

    • broker refers to the Broker that can provide the EventType. It is mandatory.

    Subscribing to events

    Now that you know what events can be consumed from the Brokers’ event meshes, you can create Triggers to subscribe to particular events.

    1. Subscribes to GitHub pushes from any source.
    1. apiVersion: eventing.knative.dev/v1
    2. kind: Trigger
    3. metadata:
    4.   name: push-trigger
    5.   namespace: default
    7.   broker: default
    8.   filter:
    9.       type: dev.knative.source.github.push
    10.   subscriber:
    11.     ref:
    12.       apiVersion: serving.knative.dev/v1
    13.       kind: Service
    14.       name: push-service

    As per the registry output above, only two sources exist for that particular type of event (knative’s eventing and serving repositories). If later on new sources are registered for GitHub pushes, this trigger will be able to consume them.

    1. Subscribes to GitHub pull requests from knative’s eventing repository.
    1. apiVersion: eventing.knative.dev/v1
    2. kind: Trigger
    3. metadata:
    4.   name: gh-knative-eventing-pull-trigger
    5.   namespace: default
    6. spec:
    7.   broker: default
    8.   filter:
    9.     attributes:
    10.       type: dev.knative.source.github.pull_request
    11.       source: https://github.com/knative/eventing
    12.   subscriber:
    13.     ref:
    14.       apiVersion: serving.knative.dev/v1
    15.       kind: Service
    16.       name: gh-knative-eventing-pull-service
    1. Subscribes to Kafka messages sent to the knative-demo topic
    1. Subscribes to PubSub messages from GCP’s knative project sent to the testing topic
    1. apiVersion: eventing.knative.dev/v1
    2. kind: Trigger
    3. metadata:
    4.   name: gcp-pubsub-knative-testing-trigger
    5.   namespace: default
    6. spec:
    8.     attributes:
    9.       source: //pubsub.googleapis.com/knative/topics/testing
    10.   subscriber:
    11.     ref:
    12.       apiVersion: serving.knative.dev/v1
    13.       kind: Service
    14.       name: gcp-pubsub-knative-testing-service

    Note that events won’t be able to be consumed by this Trigger’s subscriber until the Broker becomes ready.

    Now that we know how to discover events using the registry and how we can leverage that information to subscribe to events of interest, let’s move on to the next topic: How do we actually populate the registry in the first place?

    • Manual Registration

    In order to populate the registry, a cluster configurator can manually register the EventTypes. This means that the configurator can simply apply EventTypes yaml files, just as with any other Kubernetes resource:

    kubectl apply -f <event_type.yaml>

    • Automatic Registration

    As Manual Registration might be tedious and error-prone, we also support automatic registration of EventTypes. The creation of the EventTypes is done upon instantiation of an Event Source. We currently support automatic registration of EventTypes for the following Event Sources:

    • CronJobSource
    • ApiServerSource
    • GithubSource
    • GcpPubSubSource
    • KafkaSource
    • AwsSqsSource

    Let’s look at an example, in particular, the KafkaSource sample we used to populate the registry in our testing cluster. Below is what the yaml looks like.

    1. apiVersion: sources.knative.dev/v1beta1
    2. kind: KafkaSource
    3. metadata:
    4.   name: kafka-sample
    5.   namespace: default
    6. spec:
    7.   bootstrapServers:
    8.    - my-cluster-kafka-bootstrap.kafka:9092
    9.   topics:
    10.    - knative-demo
    11.    - news
    12.   sink:
    13.     apiVersion: eventing.knative.dev/v1
    14.     kind: Broker
    15.     name: default

    If you are interested in more information regarding configuration options of a KafkaSource, please refer to the .

    When you kubectl apply this yaml, the KafkaSource will be instantiated, and two EventTypes will be added to the registry (as there are two topics). You can see that in the registry example output from the previous sections.

    Next steps

    1. .
    2. Knative code samples is a useful resource to better understand some of the Event Sources (remember to point them to a Broker if you want automatic registration of EventTypes in the registry).