Discovering supported delivery features

[aslom]

Problem Different implementations of sources, channles, brokers may have different features affecting security, quality of service etc. but it is not possible today to discover them programmatically only by reading documentation and even then it is hard to compare as they ofetn do not use shared vocabulary.

Persona: Event consumer (developer), Event producer, System Integrator

Exit Criteria Define features (such as support for Ordering/Head of Line Blocking, Partitioning, Guaranteed Delivery) that are then added to CRDs and CRs for sources, channels and broker implementations. Demonstrate ability to query sources, channels and broker implementations for features.

Time Estimate (optional): 1w

Additional context (optional) Discussed in context of Serverless Event Streaming Meeting

[aslom]

@evankanderson @vaikas @lionelvillard @markfisher @slinkydeveloper @n3wscott please add your comments

[aslom]

@matzew that could be added to channel (or delivery?) specification? https://github.com/knative/eventing/blob/master/docs/spec/channel.md

[aslom]

@n3wscott and that could work also with duck typing?

[evankanderson]

A few items that came up so far:

• Partitioning [both number of partitions as well as partitioning function]
• Ordering / head of line blocking (I prefer the latter as it makes clear that there is a tradeoff being made)
• Batching / multi-event transactions
• Durability: at least once or at most once semantics

The first two items (at least) are important when designing streaming scenarios where state management may require seeing events in repeatable order.

I'm not sure whether these are properties of a Channel duck type, an Addressable duck type, or someplace else in the system. As an example, consider that feeding two events from an ordered channel into a non-order-preserving function (like Knative serving today) will never the output events non-ordered.

[n3wscott]

Even if a channel impl supports ordering, we don't know if our receive adapters will deliver in order based on the scaling ideas we are looking at

[slinkydeveloper]

Partitioning [both number of partitions as well as partitioning function]

To be honest, I don't understand what do you mean for partitioning in Channel abstraction. I see partitioning as a concept quite hard to abstract between different transports. Some transports could not have any support for it.

Batching / multi-event transactions

How do you perform batching? Based on what criteria? Also, you need to save state (and persist it) for intermediate event buffers, where should these buffers live? Even if we overcome these problems with some abstractions, then how we send these batches? HTTP won't be enough anymore at that point, we'll need some specific streaming protocol.

Durability: at least once or at most once semantics

I agree we should specify in the spec that we every Channel should have the at least once semantic, and we should have some specific tck/compliance test for it.

[lionelvillard]

every Channel should have the at least once semantic

not every channel. It all depends on the underlying messaging system.

[slinkydeveloper]

@lionelvillard are you proposing that Channel spec has "no delivery guarantee" semantic too?

[matzew]

I think it would be good if users could choose a Channel based on delivery features.

so for partitioning, a imaginary list could return:

• KafkaChannel
• PulsarChannel

[markfisher]

Most of these properties (perhaps apart from "is partitioning supported?") cannot be described as characteristics of the Channel alone, because the overall behavior being described spans interactions from the producer to the consumer and the ultimate handler/processor.

For example, even if a Channel is backed by a broker with strict-ordering-per-partition semantics, as soon as any downstream component adds concurrency (including load-balancing) the ordering goes out the window.

Likewise, the various levels of delivery guarantee also depend on capabilities of the dispatching/consuming side, such as inclusion of an Idempotent Receiver filter that can prevent duplicates from being passed to the ultimate handler.

Managing transaction boundaries and batching also varies with the type of underlying message broker, specifically whether consumer (group)s are responsible for managing offsets.

The point at which acknowledgements are made (at the handoff to a processor app/function or only after that processing app/function itself determines it has handled the event successfully) also impacts both the delivery guarantee level and the transaction boundaries.

[lionelvillard]

@slinkydeveloper not at all. I'm just saying Knative Eventing should not be restricted to only support at least one guarantee.

And I agree with @markfisher guarantees go beyond the underlying messaging system itself.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[aslom]

/reopen

[slinkydeveloper]

Is that related to #4868? Can we close it in favour of #4868?

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.