Revisit the decision for CRD for Channels instead of single CRD with opaque data inside of it.

[vaikas]

Problem

Background:
https://docs.google.com/document/d/1IiPq5FP74mT4bm8V__dzCI7Dh2n9GCzgib_S3lboJWg/edit#heading=h.leipbgd2g5d5

'
Currently the Channels are implemented using a "provisioner" pattern. This at the highlevel means roughly the following:

1. There's one Channel CRD which contains a single field runtime.rawextension which contains all the configurable options
2. Specific Channel Controllers watch all the Channels and react when they see Spec.Provisioner being themselves

Sources are implemented using a CRD which:

1. There's one CRD per Channel implementation which contains all the configurable options in the Spec field
2. Each Source Controller watches the CRD type which it is responsible for.

This proposal is to change the Channel implementations to be just like Sources, or more generally what's typically referred to as Operators.

I believe using a single CRD for single Channel is much better design pattern and allows us to benefit from all the goodies of the CRDs for free:

1. better installation model (single CRD + Controller)
2. better validation / default pattern (webhook can inspect the incoming request and not let it into the etcd). Today this is not doable (well, there might be a way, but not a standard way)
3. better way to document / describe the configurable options (standard CRD (OpenApi schema))
4. Others too I'm sure

The one downside I can recall from previous discussions where around RBAC problems but I believe serving has solved these with the Aggregated ClusterRoles + DuckTypes. There might be others, not trying to ignore Cons, just don't recall them all (there's others in the original document)

Anyways, wanted to get some thoughts from the community, now that we have more experience writing channels, operating Knative and so forth, etc.

Persona:
Channel Implementor (Integrator?)
Operator

Exit Criteria
Revisit the decision whether Channels should be implemented as a CRD or as a provisioner

Time Estimate (optional):
unclear

Additional context (optional)
Add any other context about the feature request here.

[pmorie]

I'm supportive of avoiding being prescriptive about how people deploy things into Kube and at a gut level feel that the provisioner pattern fits the bill as prescriptive. There are so very many different tools and ways that people use to deploy things into Kube, and selection of that tool or DIY is a very personal decision for many developers. Given that we already have a very decoupled and decentralized design scheme using CRDs and duck-typing for event sources, I think that:

• Users will understand the concept and have a level of comfort with it
• Expect the flexibility from channels that using CRDs and controllers provides

I'm definitely in favor of reconsidering this before the API goes to beta. We can always retain the existing implementation as an option for people that like the existing model. Curious to know what others feel in this area.

[vaikas]

Putting this into 0.6 so we can vote on it also

[csantanapr]

+1 "Operator" all the things

[akashrv]

Just noting down another perspective that will also help make an informed decision:

Questions is: Will channels be exposed to developers or will they be used by operators only?

One pro of provisioner pattern + default provisioner is that the developer doesn't have to worry about the underlying eventing tech or type of channels. The operator has configured the default one and as a developer I just create a channel (with no provisioner) and a subscription and things work.

With individual CRDs that goes away and a developer has to explicitly decide the channel type each time and need to know about the underlying eventing tech (such as Kafka channel or GCP channel)

With Broker/Trigger we have kind of solved this already by providing a higher level construct of Broker that encapsulates the underlying eventing infra and is defined by the operator, hence the question is whether we expect channels to be directly used by developers?

This is similar to StorageClass. The operator has defined a default one, and most developers create PersistentVolumeClaim with no storage class to leverage dynamic provisioning as defined by the operator.

[Harwayne]

/assign

[grantr]

One pro of provisioner pattern + default provisioner is that the developer doesn't have to worry about the underlying eventing tech or type of channels. The operator has configured the default one and as a developer I just create a channel (with no provisioner) and a subscription and things work.

The default Channel CRD could coexist alongside the individual CRDs. The default channel controller would become the Channel controller and would be responsible for creating an instance of the individual channel CRD that has been selected as the default whenever a Channel is created. It's slightly more complicated than the current default channel controller but not overwhelmingly so.

I'm not asserting this is a good idea or not, just pointing out that the developer's experience of default channel functionality is orthogonal to the CRD decision in this issue.

[Harwayne]

Channel Provisioners vs. CRDs documents the trade-offs for provisioners vs. CRDs.

[vaikas]

https://docs.google.com/spreadsheets/d/14uj8A3NzGhHzCbcRbVnLItHhRytct09M9jxRGykrhcw/edit#gid=0