knative/eventing-contrib

Event Sources

[EOL] Knative Eventing Contrib

This repo has been archived

The Knative Eventing Contrib project provides source and channel implementations that:

• Integrate with Apache Camel-K - new location: https://github.com/knative-sandbox/eventing-camel
• Integrate with Apache CouchDB - new location: https://github.com/knative-sandbox/eventing-couchdb
• Integrate with Apache Kafka - new location: https://github.com/knative-sandbox/eventing-kafka (consolidated)
• Integrate with AWS SQS - new location: https://github.com/knative-sandbox/eventing-awssqs
• Integrate with GitHub - new location: https://github.com/knative-sandbox/eventing-github
• Integrate with GitLab - new location: https://github.com/knative-sandbox/eventing-gitlab
• Integrate with NATS Streaming - new location: https://github.com/knative-sandbox/eventing-natss
• Integrate with Websockets
• Sample code and tools - new location: https://github.com/knative/eventing
• Expose an ingress

For complete documentation about Knative Eventing, see the following repos:

• Knative Eventing for the Knative Eventing spec.
• Knative docs for an overview of Knative and to view user documentation.

If you are interested in contributing, see CONTRIBUTING.md and DEVELOPMENT.md.

eventing-contrib's Issues

Support changes to metadata in reconciled object for sdk

Implement a source like the original eventing feedlet sources.

Expected Behavior

This will be passed:

• a service account to run as
• a start image
• a stop image

Thinking of calling this ... SimpleSource

Create a CloudEvents Ingress source

A useful generic Source would be a Source which sets up routing from the external world to an Addressable (which may have an address which only exists within the cluster). This would assume that the incoming data was in CloudEvents format, and might be able to perform authentication and credential exchange within the cluster.

Implementation-wise, this could be another event source which using Knative Serving, or could be direct configuration of Istio/whatnot. (The advantage of using Serving is that Serving already needs to solve the ingress/TLS/multi-routing problems.)

Reasons to make a generic Source rather than simply use Knative Serving/whatnot directly:

1. We can use this to start applying policy (e.g. Auth)
2. Allows you to deliver external CloudEvents to a Channel.
3. Better capture the flow of events.

we should be testing this inlined method (need mock pubsub client)

Originally posted by @Harwayne in #81

Update source resolvers to use Addressable

Expected Behavior

Channels now use Addressable, Sources need to use that to resolve.

Actual Behavior

They don't.

Steps to Reproduce the Problem

Additional Info

knative/eventing#583

GCP PubSub Source fails after first create

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Additional Info

cannot list events when kubernetes event source starts

Expected Behavior

Service account is used to authenticate to k8s API server and role/rolebinding are enforced.

Actual Behavior

Despite properly setup role/rolebinding for a k8s event source setup in a specific namespace, the test-events pod started by the kuberneteseventsource cannot get the list of events.

I believe that the culprit is:

https://github.com/knative/eventing-sources/blob/master/pkg/adapter/kubernetesevents/adapter.go#L54

Which does not load the SA secrets to get bearer token.

Steps to Reproduce the Problem

Do:

1.https://github.com/knative/docs/tree/master/eventing/samples/kubernetes-event-source

In a non default namespace where the SA has no admin privileges.

Additional Info

Use this:

https://github.com/kubernetes/client-go/blob/master/rest/config.go#L315

Allow all namespaces in kubeeventsource

Expected Behavior

When passing namespace="" I expect to be able to gather events from all namespaces

Actual Behavior

Spec is rejected

Steps to Reproduce the Problem

1. Create kuberneteseventsource with

apiVersion: sources.eventing.knative.dev/v1alpha1
kind: KubernetesEventSource
metadata:
  name: testevents
spec:
  namespace: ""
  serviceAccountName: events-sa
  sink:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Channel
    name: testchannel

Additional Info

Kuberneteseventsource explicitly block namespace= ""

Where as apimachinery explicitly defines NamespaceAll=""

Nightly releases are failing since 12/19/2019

Expected Behavior

Each day a release.yaml is published to https://console.cloud.google.com/storage/browser/knative-nightly/eventing-sources/latest and the images are published to
http://gcr.io/knative-nightly/github.com/knative/eventing-sources

Actual Behavior

The latest release.yaml file and images have been published 10 days ago.

Additional Info

The pipeline is failing due to the following error:

W1229 09:29:10.341] 2018/12/29 09:29:10 error processing import paths in "config/default.yaml": no token in bearer response:
W1229 09:29:10.341] {"errors":[{"code":"DENIED","message":"Token exchange failed for project 'knative-nightly'. Caller does not have permission 'storage.buckets.get'. To configure permissions, follow instructions at: https://cloud.google.com/container-registry/docs/access-control"}]}
W1229 09:29:10.361] Run: ('/workspace/./test-infra/jenkins/../scenarios/../hack/coalesce.py',)
E1229 09:29:10.405] Command failed
I1229 09:29:10.405] process 465 exited with code 1 after 12.1m
E1229 09:29:10.406] FAIL: ci-knative-eventing-sources-nightly-release

Move eventing/pkg/events to pkg/ ?

Will this package continue to exist in knative after knative/eventing#532 is merged? If we intend to share it, maybe it should move to knative/pkg.

Originally posted by @grantr in #27

Add guidelines for when to make a CRD based source vs leverage an existing source

from slack:

nicholss [7:17 AM]
I think the line is when you need to talk to k8s

I need to write this down in the container source (edited)
but my current thinking is the container source can make calls to external things, and act as a gateway

Add default telemetry.

Add it.

Define what is required to be considered a source, as a concept.

Like:

• tagets a sink
• has a status of X Y Z
• is labeled like X
• the CRD has a Y label
• the CRD is in X Y Z k8s categories.

kubernetes events pks return an error

Expected Behavior

Capture K8s event

Actual Behavior

k logs testevents-wp52t-kjmj4-7b78887847-rd5p5 -c source
E1115 09:45:06.120719       1 reflector.go:205] github.com/knative/eventing-sources/pkg/adapter/kubernetesevents/adapter.go:72: Failed to list *v1.Event: Get https://10.96.0.1:443/api/v1/namespaces/default/events?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: connect: connection refused

Steps to Reproduce the Problem

1. install knative eventing: https://github.com/knative/docs/tree/master/eventing#installation
2. install K8s-event-source: https://github.com/knative/docs/tree/master/eventing/samples/kubernetes-event-source
3. when k8s-events is created with correct sa, source container returns an error in its logs

Additional Info

make it easier to see installed Source CRs in a cluster.

Expected Behavior

it's a bit tricky to see what CRs for sources have been installed. by convention if we just label the created CRs consistently, we'll be able to provide a cleaner user experience.

For example, I can see available sources because I have tagged the CR created like so:

https://github.com/vaikas-google/csr/blob/master/config/cloudschedulersource.yaml#L7

vaikas@penguin:~/projects/go/src/github.com/vaikas-google$ kubectl get crds -l "eventing.knative.dev/source=true"
NAME AGE
cloudschedulersources.sources.aikas.org 50d
gcssources.sources.aikas.org 21h

Actual Behavior

you have to iterate through all the CRDs to see if they are sources. For example, these all come from the eventing-sources but are not easily discoverable.

vaikas@penguin:~/projects/go/src/github.com/vaikas-google$ kubectl get crds | grep sources.eventing
containersources.sources.eventing.knative.dev 58d
cronjobsources.sources.eventing.knative.dev 7h
gcppubsubsources.sources.eventing.knative.dev 58d
githubsources.sources.eventing.knative.dev 58d
kuberneteseventsources.sources.eventing.knative.dev 58d

Additional Info

I'm not wedded to the particular label, but sooner we agree on a convention, better off we are.

Add a sample for github source in knative/docs/eventing/samples

Expected Behavior

knative/docs repo contains workable examples for Knative Eventing examples including github.

Actual Behavior

Currently has an out of date one, will remove it from there.

Additional Info

Should be done in conjunction with: #36

Allow scaling of ContainerSources

Expected Behavior

ContainerSource objects scale with load.

Actual Behavior

ContainerSource replicas are hardcoded to 1, and it's difficult for the user to change that because the Deployment has a generated name.

Additional Info

Options include:

• Automatically create an HPA or something similar scaling the controlled Deployment. Easiest for basic cases but sacrifices flexibility.
• Support the scale subresource, allowing users to create an HPA targeting the ContainerSource. More flexibility but users are responsible for setting up autoscaling.

Return errors and let caller log instead of logging in nested functions

Originally posted by @grantr in #16 (comment)

/assign @n3wscott

Support Finalizers for sdk

/assign @adamharwayne

Github Source doesn't handle (or reject) changes to spec.eventTypes

Expected Behavior

I'd expect the controller to update the webhook with the new event types, or (worse) reject the mutation via the webhook.

Actual Behavior

The change is silently accepted and does nothing.

Repro

Try adding the following to the source sample:

spec:
  eventTypes:
  - pull_request
  - pull_request_review
  - pull_request_review_comment

Then "edit" the webhook configuration in Github, and no new even types are checked.

inline k8s corev1 Container over ContainerSourceSpec

Expected Behavior

ContainerSourceSpec has some but not all k8s corev1 Container. If k8s corev1 Container is inlined here, we then don't need to hardcode the pull policy here and will make is easier for sources that base on ContainerSource.

Actual Behavior

Steps to Reproduce the Problem

Additional Info

@n3wscott @grantr

k8s eventsource not working

Expected Behavior

seeing k8s events floating into my serving function

Actual Behavior

stacktrace on the eventing-controller when ko apply for the subscription.yaml

Steps to Reproduce the Problem

1. run the k8s event soruce sample from @vaikas-google
2. get the log from the eventing-controller in the knative-eventing ns

Additional Info

I have build from master (ko apply) of the eventing repo

W1106 11:06:49.367163       1 reconcile.go:102] Failed to resolve Subscriber {Ref:&ObjectReference{Kind:Service,Namespace:,Name:message-dumper,UID:,APIVersion:serving.knative.dev/v1alpha1,ResourceVersion:,FieldPath:,} DNSName:<nil>} : status does not contain targetable
{"level":"error","ts":1541502409.3672247,"logger":"kubebuilder.controller","caller":"controller/controller.go:209","msg":"Reconciler error","Controller":"subscription-controller","Request":"myproject/testevents-subscription","error":"status does not contain targetable","stacktrace":"github.com/knative/eventing/vendor/github.com/go-logr/zapr.(*zapLogger).Error\n\t/home/matzew/go/src/github.com/knative/eventing/vendor/github.com/go-logr/zapr/zapr.go:128\ngithub.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/matzew/go/src/github.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:209\ngithub.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1\n\t/home/matzew/go/src/github.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:157\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1\n\t/home/matzew/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:133\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil\n\t/home/matzew/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:134\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.Until\n\t/home/matzew/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:88"}

ReceiveAdapter can't talk to Channels by default.

Expected Behavior

When I create a KubernetesEventSource it should be able to talk to the Channels.

Actual Behavior

It can't due to Istio side cars.

Steps to Reproduce the Problem

1. Create KubernetesEventSource
2. it can talk to k8s event api and receive events (but see #49 )
3. can't talk to channel

Additional Info

Examples for consuming sources should show how to deserialize the event.

Expected Behavior

Easy consumption example missing. We should have a real sample for creating a function consuming pubsub events (or for each of the sources) that a user could take and use as a goby

Actual Behavior

we use the message dumper which dumps the entire http message, which is great for debugging, but what the user really cares about is consuming their event. We should have an example scaffolding that shows how the user gets the actual event.

Steps to Reproduce the Problem

1. Run through the examples (say pubsub, not picking on it, just been using it)
2. the example dumps the entire http message

Additional Info

passing secret to ContainerSource

I am building a new source based on container source. It is really awkward I have to plaintext secret in env.

I am contemplating a probable solution that could work this way:

• adding a SecretReference to ContainerSourceSpec.
• by the time the deployment is created, the secret is revealed and appended into the container's env.
• container has to know the name of the env var and get the secret.

That at least gives us a chance to provide and retrieve non-plaintext secret.

@n3wscott @grantr

Need ability to specify which service account to run *Sources as

Expected Behavior

For example, in #48 the Receive Adapter which connects to the k8s API server, it needs permissions to be able to watch for events. Currently the Deployment created by KubernetesEventSource (and because it uses ContainerSource) runs as the default service account:
serviceAccount: default
serviceAccountName: default

That means that the user needs to grant this account permissions to watch for k8s events which is undesirable. It would be better to be able to specify the Service Account that should be used so that it can be RBAC'd appropriately.

Actual Behavior

Doesn't work unless you grant rights to default/default ServiceAccount

Steps to Reproduce the Problem

1. Create KubernetesEventSource or ContainerSource and watch
2. Observe the Deployment / Pods created
3. See they run as default service account.

Additional Info

duck for namespaceable? :)

eventing sources namespace

https://github.com/knative/eventing-sources/blob/master/config/default/kustomization.yaml#L2

What do people feel about changing the namespace to knative-eventing-sources ?

Not sure if eventing-sources-system is a good choice

Break apart the manager for each source controller into an independently releasable and installable controller

Expected Behavior

Sources are independently releasable, installable and updatable.

Actual Behavior

Source manager is shared for all sources in eventing-sources making the shared controller deploy fragile.

Steps to Reproduce the Problem

1. Install a source.
2. Note the controller reconciles all supported sources.
3. Note again that adding new sources adds complexity to the existing sources.

Additional Info

We did this to move fast, and now have learned that it does let us move fast in development but it also slows us down for releases. Releases are more important.

k8s event source doesn't work on release 0.3.0

Expected Behavior

k8s event sample should work on a knative deployment using 0.3.0 release

Actual Behavior

k8s event source doesn't work, there are error in the logs

Steps to Reproduce the Problem

1. Minikube

for mac Carlo's way 😄

minikube delete
minikube config set kubernetes-version v1.11.6
minikube config set cpus 4
minikube config set memory 8192
minikube config set WantUpdateNotification false
minikube start --extra-config=apiserver.enable-admission-plugins="LimitRanger,NamespaceExists,NamespaceLifecycle,ResourceQuota,ServiceAccount,DefaultStorageClass,MutatingAdmissionWebhook"
minikube ssh -- sudo ip link set docker0 promisc on

2. Install Istio

curl -OL https://github.com/knative/serving/releases/download/v0.3.0/istio-crds.yaml
kubectl apply -f istio-crds.yaml

curl -OL https://github.com/knative/serving/releases/download/v0.3.0/istio-lean.yaml
cat istio-lean.yaml | sed 's/LoadBalancer/NodePort/' | kubectl apply --filename -

3. Install Knative Serving

curl -OL https://github.com/knative/serving/releases/download/v0.3.0/serving.yaml
cat serving.yaml | sed 's/LoadBalancer/NodePort/' | kubectl apply --filename -
watch kubectl get pods --namespace knative-serving

curl -OL https://github.com/knative/serving/releases/download/v0.3.0/monitoring.yaml
kubectl apply -f monitoring.yaml

3. Install Eventing

curl -OL https://github.com/knative/eventing/releases/download/v0.3.0/eventing.yaml
kubectl apply -f eventing.yaml
watch kubectl get pods --namespace knative-eventing

4. Install Event Sources

curl -o event-sources.yaml -L https://github.com/knative/eventing-sources/releases/download/v0.3.0/release.yaml
kubectl apply -f event-sources.yaml
watch kubectl get pods --namespace knative-sources

5. Knative Eventing demo

5. 1 Install Sample App msg dumper

curl -o message-dumper-0.3.0.yaml -L \
https://github.com/knative/eventing-sources/releases/download/v0.3.0/message-dumper.yaml

5. 2 K8s events source

The Channel

curl -o kubernetes-event-source-channel.yaml -L \
https://raw.githubusercontent.com/knative/docs/master/eventing/samples/kubernetes-event-source/channel.yaml
kubectl apply -f kubernetes-event-source-channel.yaml

The SA to get permission to events

curl -o kubernetes-event-source-serviceaccount.yaml -L \
https://raw.githubusercontent.com/knative/docs/master/eventing/samples/kubernetes-event-source/serviceaccount.yaml\
kubectl apply -f kubernetes-event-source-serviceaccount.yaml

The Event Source

curl -o kubernetes-event-source-k8s-events.yaml -L \
https://raw.githubusercontent.com/knative/docs/master/eventing/samples/kubernetes-event-source/k8s-events.yaml
kubectl apply -f kubernetes-event-source-k8s-events.yaml

The Subscription

curl -o kubernetes-event-source-subscription.yaml -L \
https://raw.githubusercontent.com/knative/docs/master/eventing/samples/kubernetes-event-source/subscription.yaml
kubectl apply -f kubernetes-event-source-subscription.yaml

Test it !
Create a pod

kubectl run -i --tty busybox --image=busybox --restart=Never -- sh

Delete a pod

kubectl delete pod busybox

Verify

kubectl get pods
kubectl logs -l serving.knative.dev/service=message-dumper -c user-container

Here are the logs collected on a 1.11.6 cluster

kubectl logs controller-manager-0 -n knative-sources
{"level":"info","ts":1547218967.8800313,"logger":"fallback","caller":"sdk/reconciler.go:52","msg":"Reconciling &TypeMeta{Kind:,APIVersion:,} default/testevents-qx7cn"}
{"level":"warn","ts":1547218967.8907819,"logger":"fallback","caller":"sdk/reconciler.go:74","msg":"Failed to reconcile &TypeMeta{Kind:,APIVersion:,}: sink \"default/testchannel\" (eventing.knative.dev/v1alpha1, Kind=Channel) does not contain address"}

in the the eventing controller

kubectl logs eventing-controller-847d8cf969-dzwzq -n knative-eventing
{"level":"info","ts":1547218501.9501147,"logger":"kubebuilder.controller","caller":"controller/controller.go:153","msg":"Starting workers","Controller":"subscription-controller","WorkerCount":1}
I0111 15:02:57.075128       1 reconcile.go:51] Reconciling subscription default/testevents-subscription
I0111 15:02:57.075358       1 reconcile.go:87] DeletionTimestamp: <nil>
W0111 15:02:57.089030       1 reconcile.go:230] Failed to fetch SubscriberSpec target &ObjectReference{Kind:Service,Namespace:,Name:message-dumper,UID:,APIVersion:serving.knative.dev/v1alpha1,ResourceVersion:,FieldPath:,}: services.serving.knative.dev "message-dumper" not found
W0111 15:02:57.089100       1 reconcile.go:114] Failed to resolve Subscriber {Ref:&ObjectReference{Kind:Service,Namespace:,Name:message-dumper,UID:,APIVersion:serving.knative.dev/v1alpha1,ResourceVersion:,FieldPath:,} DNSName:<nil>} : services.serving.knative.dev "message-dumper" not found
{"level":"error","ts":1547218977.0960505,"logger":"kubebuilder.controller","caller":"controller/controller.go:209","msg":"Reconciler error","Controller":"subscription-controller","Request":"default/testevents-subscription","error":"services.serving.knative.dev \"message-dumper\" not found","stacktrace":"github.com/knative/eventing/vendor/github.com/go-logr/zapr.(*zapLogger).Error\n\t/home/argent/go/src/github.com/knative/eventing/vendor/github.com/go-logr/zapr/zapr.go:128\ngithub.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/argent/go/src/github.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:209\ngithub.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1\n\t/home/argent/go/src/github.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:157\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1\n\t/home/argent/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:133\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil\n\t/home/argent/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:134\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.Until\n\t/home/argent/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:88"}
I0111 15:02:58.096549       1 reconcile.go:51] Reconciling subscription default/testevents-subscription
I0111 15:02:58.097026       1 reconcile.go:87] DeletionTimestamp: <nil>
W0111 15:02:58.101593       1 reconcile.go:114] Failed to resolve Subscriber {Ref:&ObjectReference{Kind:Service,Namespace:,Name:message-dumper,UID:,APIVersion:serving.knative.dev/v1alpha1,ResourceVersion:,FieldPath:,} DNSName:<nil>} : status does not contain address
{"level":"error","ts":1547218978.1018186,"logger":"kubebuilder.controller","caller":"controller/controller.go:209","msg":"Reconciler error","Controller":"subscription-controller","Request":"default/testevents-subscription","error":"status does not contain address","stacktrace":"github.com/knative/eventing/vendor/github.com/go-logr/zapr.(*zapLogger).Error\n\t/home/argent/go/src/github.com/knative/eventing/vendor/github.com/go-logr/zapr/zapr.go:128\ngithub.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/argent/go/src/github.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:209\ngithub.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1\n\t/home/argent/go/src/github.com/knative/eventing/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:157\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1\n\t/home/argent/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:133\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil\n\t/home/argent/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:134\ngithub.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait.Until\n\t/home/argent/go/src/github.com/knative/eventing/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:88"}

Additional Info

installation of kustomize is not documented.

Expected Behavior

scripts to work after development requirements have been done.

Actual Behavior

get an error about missing kustomize

Steps to Reproduce the Problem

1. check out the repo
2. update things
3. run ./hack/update-manifests.sh
4. things fail

Additional Info

Fails with:
vaikas@penguin:~/projects/go/src/github.com/knative/eventing-sources$ ./hack/update-manifests.sh
CRD manifests generated under '/home/vaikas/projects/go/src/github.com/knative/eventing-sources/config/crds'
RBAC manifests generated under '/home/vaikas/projects/go/src/github.com/knative/eventing-sources/config/rbac'
./hack/update-manifests.sh: line 32: kustomize: command not found

ContainerSource needs a soft delete to unhook anything hooked.

#16 (comment)

When a container source is deleted, we need to signal to the deployment pod that it will be deleted soon. We could do something that requires the ContainerSource to have a finalizer and an endpoint to shutdown or a status or something.

Design this integration.

I wonder if we should make a followup to consolidate conditions for sources.

Originally posted by @n3wscott in https://github.com/knative/eventing-sources/diffs

Releases are broken

Expected Behavior

Releases are not broken. :)

Actual Behavior

Since 10/25, release.sh fails with:

W1102 09:31:00.946] 2018/11/02 09:31:00 error processing import paths in "config/default.yaml": no token in bearer response:
W1102 09:31:00.946] {"errors":[{"code":"NAME_INVALID","message":"Invalid resource name: \"repository:knative-releases/github.com/knative/eventing-sources/cmd/kuberneteseventsource/:push,pull\", must match: \"[a-z0-9._-]+(?:/[a-z0-9._-]+)*\""}]}

Steps to Reproduce the Problem

1. Run hack/release.sh

Additional Info

Proposal: Awesome Knative Eventing Sources

Expected Behavior

Initial version of a Catalog solution for Sources that could a structured document, as discussed on the roadmap: https://docs.google.com/document/d/1z0z412rL9FsBsF8kwKxG6w7sflJLKe9hIECkc7jWfOY/edit?disco=AAAACRGJwCE

Proposal

Instead of creating such a file here, I'd think that creating a separate "knative-awesome" repo is actually better. This allows all Knative communities, to have some kind of "reference" for things build for, or on-top of the different knative components.

The Red Hat / CoreOS Operator framework does have such a repo:

• https://github.com/operator-framework/awesome-operators

This could be a good first step.

/cc @vaikas-google @mattmoor @evankanderson

Create a debugging / tracing decoding guide

We should have a page that describes how to debug failed events, how to read traces, etc.

default source file confusion

More a question...

why does the default-gcppubsub file contain four sources?

• ContainerSource
• GcpPubSubSource
• GitHubSource
• KubernetesEventSource

I think I'd expect it is just GcpPubSubSource that's in there.

The default on the other hand, contains:

• ContainerSource
• GitHubSource
• KubernetesEventSource

Not sure I agree the GitHubSource is in there - seems a bit specialised, so would have expected only ContainerSource and KubernetesEventSource in that default file.

Would it make sense to have only the PubSub source in pubsub.yaml file? Similar for Github?

CRDs have invalid schema definitions with status enabled

https://gubernator.knative.dev/build/knative-prow/pr-logs/pull/knative_eventing/622/pull-knative-eventing-integration-tests/1063116345668800514 is failing due to an error creating the containersource CRD.

The validation error is:

must only have "properties", "required" or "description" at the root if the status subresource is enabled

The generated CRDs have the type field and that's causing a new validation failure that only occurs when status is enabled.

See kubernetes/kubernetes#65293 and kubernetes/kubernetes#65357 for the issue and fix, which unfortunately hasn't been backported to 1.11.

kubernetes-sigs/controller-tools#72 fixes the generated yamls, so I think we just have to upgrade to the correct version of that.

This isn't an issue for any project that doesn't use controller-tools to generate CRD yaml.

Better logging format

Would be nice to get some prettier logging format for the controller

see:

{"level":"info","ts":1544035043.6600838,"logger":"fallback","caller":"sdk/reconciler.go:53","msg":"Reconciling &TypeMeta{Kind:,APIVersion:,} metr1ckzu/gh1"}

Especially the timestamp, a human readable date would be cool.

ContainerSource should recreate the deployment if args or image change.

Expected Behavior

Deployments reflect current settings

Actual Behavior

Deployments reflect first settings.

Graceful shutdown of subscriptions in GCP PubSub receive adapter

The normal usage of sub.Receive is to pass it a cancelable context. Then cancel from the outside when appropriate. But because all this program is doing is receiving messages (and we don't have any shutdown logic), there is no reason to call cancel.

We probably should add graceful shutdown logic, but I would rather do that in the future than in this PR. At worst what will happen is a message will be processed multiple times (i.e. it is sent downstream, but not ACKed, and the RA is shutdown, the new RA sends the same message downstream again).

Originally posted by @adamharwayne in https://github.com/knative/eventing-sources/pull/39/files#r229334215

Write E2E tests

Github Source doesn't surface failures registering webhook

Original issue: knative/docs#554

Think about the source contract for knative

https://github.com/knative/eventing/pull/482/files#r226756604

Github Source drops critical header

/kind bug

I am trying to use the github.com/google/go-github library to handle events received through the Github event source, and it seems that a key header is being dropped.

From my own logging:

ERROR: unable to parse webhook: unknown X-Github-Event in message:

What I'm doing is largely following the sample usage here, with the exception that I don't call ValidatePayload because that secret verification is managed by the github event source.

Here's the code printing the above error:

        event, err := github.ParseWebHook(github.WebHookType(r), payload)
        if err != nil {
                log.Printf("ERROR: unable to parse webhook: %v", err)
                http.Error(w, err.Error(), http.StatusBadRequest)
                return
        }

Making sure this sample usage works feels like it would be a great e2e test for this event source.

Note: I'm not sure if the "github source" or the "in-memory-channel" it proxies through is dropping the header.

Create a Webhook for Eventing-Sources

Originally posted by @n3wscott in #39

Container Source args

the container source args:

e.g. in here:
https://github.com/knative/eventing-sources/blob/master/config/samples/sources_v1alpha1_containersources.yaml#L9-L11

can they be populated by ENV_VARs?

Document what Container Source does, will do, and should do.

People need better documentation for this resource.

As a user, I want Google events

Expected Behavior

The open source software Google uses interacts with Google Cloud

Actual Behavior

Google's events are only routed to Cloud Functions

Steps to Reproduce the Problem

1. Read docs

Additional Info

We should build another event source proxy (this time for *.googleapis.com). We can start by just deploying a Cloud Function that sends our cluster Cloud Events via a webhook. Future features in Google's hosted products can make this a direct connection.

don't inject istio by default

istio sidecar is injected into container source by default here. And there is no document on it or service entry. I notice only container source and gcp pubsub have it, github source doesn't have it (a right thing imo)

I may have missed the big picture, but is there a reason to force istio on? @grantr @n3wscott

kubebuilder create command fails due to missing Makefile

Expected Behavior

kubebuilder create api runs without errors

Actual Behavior

$ kubebuilder create api --group sources --version v1alpha1 --kind KubernetesEventSource
Create Resource under pkg/apis [y/n]?
y
Create Controller under pkg/controller [y/n]?
y
Writing scaffold for you to edit...
pkg/apis/sources/v1alpha1/kuberneteseventsource_types.go
pkg/apis/sources/v1alpha1/kuberneteseventsource_types_test.go
pkg/controller/kuberneteseventsource/kuberneteseventsource_controller.go
pkg/controller/kuberneteseventsource/kuberneteseventsource_controller_test.go
Running make...
make: *** No targets specified and no makefile found.  Stop.
2018/10/24 10:55:35 exit status 2

Must then run hack/update-codegen.sh && hack/update-manifests.sh manually.

/cc @n3wscott