Clarify that only a Channel is subscribable

[scothis]

The Subscription resource already said that the from property ObjectRef was required to be a Channel, but the remainder of the spec implied otherwise.

• remove Subscribable interface (it doesn't need to exist if only a single resource can be referenced by Subscriptions)
• a Source is no longer expected to ever create a Channel (a higher level resource can create both a Source and Channel)
  • Source now requires a Channel ObjectRef
• cleanup language around the role of a Source

[grantr]

If only a Channel can be Subscribable, what's the solution to knative#508? (generally: a Source that is capable of fanout must be fanned out separately due to this restriction)

I think there should be a very compelling reason for disallowing a Source to fanout on its own, since that translates directly into decreased efficiency for users and implementers that they cannot overcome.

[scothis]

If only a Channel can be Subscribable, what's the solution to knative#508?

Create a new Source for each "Subscription" targeting the result/Sinkable.

A Source should be relatively light since most of the infrastructure is now centralized by the provisioner. If there is complex configuration for the Source, a higher order resource can decompose to a set of Sources.

[grantr]

Create a new Source for each "Subscription" targeting each of the result's Sinkable.

I'm not sure I understand, can you elaborate on this? What is a "Subscription"? What creates the Source and how does it know about the result? What object contains the result value?

[scothis]

A source with multiple subscriptions

Source -> Subscription A -> Channel A
       -> Subscription B -> Channel B
       -> Subscription C -> Channel C

becomes multiple sources with no subscriptions

Source A -> Channel A
Source B -> Channel B
Source C -> Channel C

Each of Source A, B and C use the same Provisioner and the same configuration except for the channel field which is set from the result.target field of each of Subscription A, B and C.

[matzew]

👍

[vaikas]

This is fine as in source always puts things into a channel. However, I think it would be nice if a user wouldn't have to go digging into objects and then cut&paste these Channels around when creating pipelines. Hence the ability to deref, just like with Targetable, we could require a user to go in and at the lowest level just say it's a DNS name, same kind of applies here as in it's not ideal, if we think Targetable is a good concept, this is the same but in reverse.

[matzew]

a Source is no longer expected to ever create a Channel (a higher level resource can create both a Source and Channel)

I agree that a source should not create a Channel. This higher level resource you talk here is the kind: Provisioner - right ?

[matzew]

A source with multiple subscriptions

Source -> Subscription A -> Channel A
       -> Subscription B -> Channel B
       -> Subscription C -> Channel C

becomes multiple sources with no subscriptions

Source A -> Channel A
Source B -> Channel B
Source C -> Channel C

Each of Source A, B and C use the same Provisioner and the same configuration except for the channel field which is set from the result.target field of each of Subscription A, B and C.

I am not really sure I do get that

[deissnerk]

@grantr In knative#508 I was suggesting that Channels should support more protocols. In my example it was:

Source (Topic) -> Channel -> Subscription A (Queue A) 
                          -> Subscription B (Queue B) 

[matzew]

I think with this change, the drawing in https://docs.google.com/drawings/d/10mmXzDb8S_4_ZG_hcBr7s4HPISyBqcqeJLTXLwkilRc/edit needs update too

[n3wscott]

merged.