5 ms·

I'm a bit confused about the "eventing" application. Is it a message bus like NATS? a persistent event log like Kafka? or is it an adapter that allows applicati

I'm a bit confused about the "eventing" application. Is it a message bus like NATS? a persistent event log like Kafka? or is it an adapter that allows applications to interact with both?

jacques_chester 8y ago
Eventing provides primitives that can use messaging systems under the hood (Buses). But it's meant to be a higher level abstraction for connecting functions or applications.
inlined 8y ago
The eventing repo provides a common pluggable model for managing events. The communication layer is currently HTTP, not NATS. But the broker is pluggable and includes support for Kafka. You can choose to use Kafka throughout your cluster or just for a single feed. You can add other implementations as well. The three pluggable abstractions are your event sources, the bus over which events are stored/sent, and the actions which should be invoked in response to an event.
evankanderson 8y ago
"eventing" is building an ecosystem to make it easy to connect events to event consumers (whether they are Knative Services, k8s services, VMs, or even a SaaS). In order to do this, we've broken the problem down into 3 parts: Buses provide a k8s-native abstraction over message buses like NATS or Kafka. At this level, the abstraction is basically publish-subscribe; events are published to a Channel, and Subscriptions route that Channel to interested parties. Sources provide a similar abstraction layer for provisioning data sources from outside Kubernetes and routing them to the cluster, expressed as a Feed (typically, to a Channel on a Bus, but could also be directly to another endpoint). Right now, we only have a few generic Sources, but we plan to add more interesting and specific Sources over time. Lastly, we have a higher-level abstraction called a Flow which bundles up the specification from the Source to the endpoint, optionally allowing you to choose the Channel and Bus which the event is routed over. (Otherwise, there is a default Bus used to provision a Channel.) All of this is also very much work-in-progress. You're seeing the workshop as we put down our tools yesterday, not as cleaned up for a tour. :-)
- villeaikas 8y ago
  Sources also can expose multiple Types of events (EventType) they can emit, for example Github has 40 or so events, so you can choose which types of events you want to consume from your handler.
- otterley 8y ago
  Can you point us to the design document so we can further study it?
  - jacques_chester 8y ago
    This one is harder to point to, eventing is still under fairly active discussion. The Eventing Glossary doc[0] and the working group notes are probably the best references right now. [0] https://docs.google.com/document/d/1JSPgieg0DiP4uIfo_zDoojo65U5G64zbTgXwgQoeaWg/edit#heading=h.4bitbo4ik33t https://docs.google.com/document/d/1JSPgieg0DiP4uIfo_zDoojo6... [1] https://docs.google.com/document/d/1uGDehQu493N_XCAT5H4XEw5T9IWlPN1o19ULOWKuPnY/edit# https://docs.google.com/document/d/1uGDehQu493N_XCAT5H4XEw5T...

I'm a bit confused about the "eventing" application. Is it a message bus like NATS? a persistent event log like Kafka? or is it an adapter that allows applications to interact with both?

jacques_chester 8y ago

Eventing provides primitives that can use messaging systems under the hood (Buses). But it's meant to be a higher level abstraction for connecting functions or applications.

inlined 8y ago

The eventing repo provides a common pluggable model for managing events. The communication layer is currently HTTP, not NATS. But the broker is pluggable and includes support for Kafka. You can choose to use Kafka throughout your cluster or just for a single feed. You can add other implementations as well. The three pluggable abstractions are your event sources, the bus over which events are stored/sent, and the actions which should be invoked in response to an event.

evankanderson 8y ago

"eventing" is building an ecosystem to make it easy to connect events to event consumers (whether they are Knative Services, k8s services, VMs, or even a SaaS). In order to do this, we've broken the problem down into 3 parts: Buses provide a k8s-native abstraction over message buses like NATS or Kafka. At this level, the abstraction is basically publish-subscribe; events are published to a Channel, and Subscriptions route that Channel to interested parties. Sources provide a similar abstraction layer for provisioning data sources from outside Kubernetes and routing them to the cluster, expressed as a Feed (typically, to a Channel on a Bus, but could also be directly to another endpoint). Right now, we only have a few generic Sources, but we plan to add more interesting and specific Sources over time. Lastly, we have a higher-level abstraction called a Flow which bundles up the specification from the Source to the endpoint, optionally allowing you to choose the Channel and Bus which the event is routed over. (Otherwise, there is a default Bus used to provision a Channel.) All of this is also very much work-in-progress. You're seeing the workshop as we put down our tools yesterday, not as cleaned up for a tour. :-)

villeaikas 8y ago
Sources also can expose multiple Types of events (EventType) they can emit, for example Github has 40 or so events, so you can choose which types of events you want to consume from your handler.
otterley 8y ago
Can you point us to the design document so we can further study it?
- jacques_chester 8y ago
  This one is harder to point to, eventing is still under fairly active discussion. The Eventing Glossary doc[0] and the working group notes are probably the best references right now. [0] https://docs.google.com/document/d/1JSPgieg0DiP4uIfo_zDoojo65U5G64zbTgXwgQoeaWg/edit#heading=h.4bitbo4ik33t https://docs.google.com/document/d/1JSPgieg0DiP4uIfo_zDoojo6... [1] https://docs.google.com/document/d/1uGDehQu493N_XCAT5H4XEw5T9IWlPN1o19ULOWKuPnY/edit# https://docs.google.com/document/d/1uGDehQu493N_XCAT5H4XEw5T...