Emitting corev1 Events for debugging purposes

[nachocano]

Fixes #724

Proposed Changes

• Adding corev1.Events to InMemoryChannel, ClusterChannelProvisioner and Subscription objects in their respective reconcile processes, in order to make debugging easier.
• Adding a MockEventRecorder that contains a slice with the events emitted, and verifies their existence afterwards.
• Adding permissions to manipulate events to the in-memory-channel default configuration
• Here is the list of the events emitted:

InMemoryChannel

Name	Type	Description
ChannelConfigSyncFailed	Warning	When the Channel's config couldn't be synced. Includes the go error string.
K8sServiceCreateFailed	Warning	When the K8s Service couldn't be created. Includes the go error string.
VirtualServiceCreateFailed	Warning	When the Virtual Service couldn't be created. Includes the go error string.
ChannelUpdateStatusFailed	Warning	When the Channel's status couldn't be updated. It can happen even if the reconciliation process was successful. Includes the go error string.
ChannelReconciled	Normal	When the Channel's reconciliation process succeeds. This is the "Success" event. Includes the channel name.

ClusterChannelProvisioner

Name	Type	Description
K8sServiceCreateFailed	Warning	When the K8s Service couldn't be created. Includes the go error string.
K8sServiceDeleteFailed	Warning	When the old K8s Service couldn't be deleted. Includes the go error string.
CcpUpdateStatusFailed	Warning	When the Ccp's status couldn't be updated. It can happen even if the reconciliation process was successful. Includes the go error string.
CcpReconciled	Normal	When the Ccp's reconciliation process succeeds. This is the "Success" event. Includes the ccp name.

Subscription

Name	Type	Description
PhysicalChannelSyncFailed	Warning	When the physical Channel couldn't not be synced. Includes the go error string.
ChannelReferenceFetchFailed	Warning	When we couldn't validate the existence of the Channel. Includes the go error string.
SubscriberResolveFailed	Warning	When we couldn't resolve the Subscriber's URI. Includes the go error string.
ResultResolveFailed	Warning	When we couldn't resolve the Subscription's reply. Includes the go error string.
SubscriptionUpdateStatusFailed	Warning	When the Subscription's status couldn't be updated. It can happen even if the reconciliation process was successful. Includes the go error string.
SubscriptionReconciled	Normal	When the reconciliation process succeeds. This is the "Success" event. Includes the subscription name.

Release Note

InMemoryChannel, ClusterChannelProvisioner, and Subscription are now more detailed when errors occur.

[nachocano]

/assign @adamharwayne @grantr

[knative-prow-robot]

@nachocano: GitHub didn't allow me to assign the following users: adamharwayne.

Note that only knative members and repo collaborators can be assigned.
For more information please see the contributor guide

In response to this:

/assign @adamharwayne @grantr

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Harwayne]

/assign @Harwayne

[nachocano]

/test pull-knative-eventing-build-tests

[vaikas]

/approve

leaving lgtm for others who made comments. Thanks for doing this!

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nachocano, vaikas-google

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vaikas-google]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[grantr]

I initially thought the build failure here was due to it trying to verify that the boilerplate header was the same in all files, but I was incorrect. Only the generated code is verified, and it's diffing the whole file, not the boilerplate header specifically.

So I think it would have been successful to update the boilerplate to 2019 here and then regenerate code. Regardless I'd prefer the boilerplate change to happen in a different PR 🙂

[Harwayne]

/lgtm
/hold

Please check the in-memory-channel-controller's logs to ensure it is not complaining about not being able to write events (perhaps just a subset of them, whereas others do get created successfully). If the logs do not have any errors, then cancel the hold.

[nachocano]

@Harwayne you were right :) I saw the patch problem again, I was looking at the wrong log before. Thanks for pointing that out. I added the patch verb and now it seems to be working fine.

[Harwayne]

@Harwayne you were right :) I saw the patch problem again, I was looking at the wrong log before. Thanks for pointing that out. I added the patch verb and now it seems to be working fine.

Can we add update just to be safe? I think this is is the relevant code https://github.com/kubernetes/client-go/blob/583180148285a4936b884d8d27ed0063146a8df6/tools/record/event.go#L47, which has create, update, and patch.

[Harwayne]

/lgtm

[nachocano]

@Harwayne you were right :) I saw the patch problem again, I was looking at the wrong log before. Thanks for pointing that out. I added the patch verb and now it seems to be working fine.

Can we add update just to be safe? I think this is is the relevant code https://github.com/kubernetes/client-go/blob/583180148285a4936b884d8d27ed0063146a8df6/tools/record/event.go#L47, which has create, update, and patch.

Done! Should have triggered another build

[Harwayne]

/hold cancel

[knative-metrics-robot]

The following is the coverage report on pkg/.
Say /test pull-knative-eventing-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/controller/eventing/inmemory/channel/reconcile.go	97.8%	97.9%	0.1
pkg/controller/eventing/inmemory/clusterchannelprovisioner/reconcile.go	94.3%	93.1%	-1.2
pkg/controller/eventing/subscription/reconcile.go	78.0%	77.6%	-0.4

[nachocano]

/test pull-knative-eventing-integration-tests

[nachocano]

@Harwayne have you seen an error like this? It seems that there is something going on with us-central1-b?

[Harwayne]

@Harwayne have you seen an error like this? It seems that there is something going on with us-central1-b?

The error is Try a different location, or try again later: Google Compute Engine does not have enough resources available to fulfill request: us-central1-b. Which is definitely a GCE error. I don't know how (or if we can) switch zones for the test. @evankanderson @adrcunha

[nachocano]

/test pull-knative-eventing-integration-tests