Align Bind.Spec.Action and Subscription.Spec.Subscriber

[scothis]

Expected Behavior

Bind.Spec.Action and Subscription.Spec.Subscriber both indicate the destination where traffic should be sent. Both Bind and Subscription should use an similar (if not the same) struct, and use the same resolution logic.

Actual Behavior

Bind.Spec.Action is a struct with routeName or channelName, while Subscription.Spec.Subscriber is a string.

Additional Info

Refs #117 (comment)

[n3wscott]

@grantr and I where talking and how does the idea of removing both Subscription and Bind objects in favor of a new object called Pipe that does the same thing for the following one way pipes.

A rough idea for Pipe would be:

apiVersion: channels.knative.dev/v1alpha1
kind: Pipe
metadata:
  name: pipe-example
  namespace: default
spec:
  from:
    eventType: pullrequest
    resource: vaikas/misc
    service: github
    parametersFrom:
      - secretKeyRef:
          name: githubsecret
          key: githubCredentials
  to:
    service: pr-reaction
    arguments: 
    - name: project
      value: awesome-app

[n3wscott]

Something to note, this adds EventType in the Pipe that becomes the replacement for a Subscription.

It also means we could make anonymous channels (implied) if a service wanted to pipe to a service.

[evankanderson]

How does this work when also using the delivery core?

We had "Channel" as a event delivery mechanism so that there was an object + name which could be referenced and reached by the actual source of the event (which might be off-cluster) in order to enqueue the event into a bus which could provide reliable delivery and queueing visibility in-cluster.

[n3wscott]

Sorry if my quick post was not a full thought, I am not suggesting that channels go away. I am saying you still do event type to channel piping, and channel to service piping. And then the conclusion you can make is that for simple situation you could have a auto generated channel onto the bus for piping a event source to a service when it makes sense.

I am saying a pipe resource replaces both a bind and a subscription. But a pipe would be used in the exact same way as those objects are currently used.

Why have two resources that mean bind/subscribe this to that? Pipe them together ?

[evankanderson]

It sounds like your idea is to have multiple controllers cooperate across the space of Pipes, and possibly even on different fields in the same pipe. The principle I've heard operate successfully in this scenario is that "each field should be written by at most one controller". The tricky parts are likely to be:

1. Having a consistent experience which is easy for customers to use and understand.
2. Representing status consistently.
3. How to represent the following scenarios:
   a. Send to a channel, route to destination
   b. Send from an event source directly to destination
   c. Send from an event source through a channel to the destination. In particular, we'd like this definition to be amenable to optimization in the controller to allow sharing resources, particularly on the upstream event source and delivery adapter where possible, though sharing channels would also be interesting.

[n3wscott]

I spiked enough of Pipe out to realize that it should not replace bind or subscription.

I think it results in a higher order object that produces Bind, Subscription, Channel, EventType, EventSource, and even Bus objects. All dependent on the exact scenarios. I am going to back-pocket the idea and work towards getting a controller for Subscriptions. Without that Pipe ... is just a pipedream

[evankanderson]

I believe that we are standardizing on an Action object which is one of: ObjectReference or string URI. See Feed for an example:

https://github.com/knative/eventing/blob/master/pkg/apis/feeds/v1alpha1/feed_types.go#L54

The justification for the object with two fields is that it is handy to be able to use object references when working within the cluster, but at the end of the day we need a DNS address/URI to deliver the events to (and URI is more convenient for off-cluster resources). When given an ObjectReference, our plan is to have a well-defined field in the object's status which indicates the DNS name used to connect to the destination.

@vaikas-google is working to convert Feed to use DNS name, since we expect that it will be used as a component of Flow more often than on its own. PR is currently on local laptop rather than on GitHub.

[vaikas]

I believe this was fixed by #269
@n3wscott @evankanderson

If you agree, please close this. If not, can we tighten up the issue more?

[evankanderson]

/close

…

On Mon, Jul 23, 2018 at 5:50 PM Ville Aikas ***@***.***> wrote: I believe this was fixed by #269 <#269> @n3wscott <https://github.com/n3wscott> @evankanderson <https://github.com/evankanderson> If you agree, please close this. If not, can we tighten up the issue more? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#118 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlyN2ppIHzmFDoGRMHOpIDj-nfVdii1ks5uJm9UgaJpZM4U3A6y> .

-- Evan Anderson <argent@google.com>