Document few messages from current event sources #860
Comments
|
/kind doc |
|
/assign |
|
My takeaways so far from this are:
|
|
fyi @akashrv |
|
I think my preferred solution to problem #1 is to add a (uninteresting fields removed from the following examples for clarity) kind: EventType
meta:
# this is advisory
name: com.github.pull_request
spec:
# this is authoritative
type: com.github.pull_requestkind: EventType
meta:
# This name is generated by stripping invalid chars from the type name and
# setting generateName on creation
name: type-with-invalid-chars-5ha6
spec:
type: "type with invalid chars 😀"The user story for "list all event types" is equivalent because the event type can still be displayed using custom columns. IMO this also simplifies (but does not solve) the problem of multiple conflicting definitions for a single type. By allowing conflicts to exist, the user (or entity creating the EventType, which may be a Broker) is not immediately responsible for resolving the conflict at creation time. Conflict resolution to be postponed to a later time, and perhaps more importantly, a resolution strategy can be selected when necessary based on the specific need. For example, an ingress validator on the data plane may want to allow an event if ANY schema matches. Separately, a control-plane conflict checker may want to generate a Kubernetes event if any two EventTypes conflict. This data model recognizes that conflicts are expected occurrences rather than invalid edge cases. For example: kind: EventType
meta:
name: com.github.pull_request
spec:
type: com.github.pull_request
schema: https://github.com/schemas/pull_request.v3.jsonThis type was created when the GitHub source adapter was installed. It specifies the Later the GitLab source adapter is installed. This adapter uses the kind: EventType
meta:
name: gitlab-pull-request
spec:
type: com.github.pull_request
schema: https://github.com/schemas/pull_request.v4.jsonThis state may not actually cause errors: v4 might be backward compatible with v3, allowing consumers to work with either. |
|
@grantr Makes sense! Let me recap. The I'm OK with having what you are proposing for a first cut, and we cover the user story of listing the types as you said. |
|
FYI @vaikas-google, @evankanderson. I think these real world examples are key to understanding what the registry should look like. Furthermore, any proposal we have should show what these events look like in that proposal. Thanks @nachocano! |
|
Also, don't think of type as headers, they are context attributes on the cloudevent, the headers are just that projection onto binary http. |
Makes sense. Should called them context attributes instead. Thanks for the clarification |
|
This help fixing #929 |
Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>
By documenting few examples of how our current event sources are sending cloud events into the eventing mesh, we might be able to better understand what we actually need for a first cut of Registry (and also some of the filtering for Broker/Trigger)
Below there are few dumps from the message_dumper. Only the HTTP headers are included. Most of the events below were sent using cloud events spec v0.1. Since then, most of the sources in eventing-sources repo have been changed to send cloud events v0.2. Note how the HTTP header names (Ce-*) change.
GitHub Event Source
pull_request
BitBucket Event Source
repo:push
GCP PubSub source
publish message to new_testing topic
Kubernetes Event Source
busybox
CronJob Event Source
schedule = "*/2 * * * *"
The text was updated successfully, but these errors were encountered: