[WIP] Alternate Broker Implementations

[n3wscott]

Problem
The broker is introduced as a blackbox component where the only the functionality is what should matter. For integrations of Knative on special situations (like a hosted solution, or integrating with existing messaging frameworks) there is a need to have more control over more of the components internal to the broker.

Persona:
Cluster Operator.
Knative Contributor.

Exit Criteria
Be able to select alternative, non-trivial broker implementations on a per-broker resource basis.

Time Estimate (optional):
14 days.

Additional context (optional)
Alternate Broker Proposal (doc)

[akashrv]

Let's make sure we have defined

• what a Broker is in terms of control plane and data plane contract?
• What makes a Broker a Knative conformant broker? Especially how end users consume it.
  Adding @grantr who has been working on this so that we can combine the effort.

[matzew]

I generally like the idea of re thinking broker, and allowing brokers without channels.

What does that mean for the current API ? Currently the API contains channelTemplateSpec field - a broker w/o channels would not need this - or should generally not expose the channels it is perhaps using, internally (if so)

How do we move forward w/ beta1 API for the broker? If we know already we prefer different broker styles... should we promote the current API to v1beta1 ?

Thoughts /cc @vaikas @n3wscott @grantr @akashrv @Abd4llA

[grantr]

/label proposal/0.14

[n3wscott]

#2456

[n3wscott]

after #2456, #2468

[evankanderson]

/assign @vaikas @lionelvillard

Needs a WG lead to assign reviewers.

[evankanderson]

(Interested parties should feel free to suggest themselves as proposal approvers for the WG lead to delegate to.)

[grantr]

✋ for approver

[grantr]

@n3wscott Seems like this is done. Can this issue be closed?