Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emit events when we fail to update the taskrun #2526

Merged
merged 1 commit into from
May 13, 2020

Conversation

afrittoli
Copy link
Member

@afrittoli afrittoli commented May 2, 2020

Changes

Similarly to how the pipeline controller does, we should emit events
when we fail to update the taskrun.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

See the contribution guide for more details.

Double check this list of stuff that's easy to miss:

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Release Notes

We now emit warning events from the taskrun controller if the controller fails to sync the updated taskrun back.

@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label May 2, 2020
@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/taskrun/taskrun.go 74.7% 74.5% -0.2

@afrittoli afrittoli force-pushed the issues/2522_emit_errors branch from a468b43 to 1f411f8 Compare May 4, 2020 09:11
@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/taskrun/taskrun.go 74.7% 74.5% -0.2

afrittoli added a commit to afrittoli/pipeline that referenced this pull request May 5, 2020
Emit additional events:
- Pipeline Start

Emit all events through the events.go module.
Align and simplify the reconcile structure to have clear points
for error handling and emitting events.

Depends on tektoncd#2543
Depends on tektoncd#2526
@afrittoli afrittoli added the kind/feature Categorizes issue or PR as related to a new feature. label May 7, 2020
Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/meow

@tekton-robot
Copy link
Collaborator

@vdemeester: cat image

In response to this:

/meow

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.

@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

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:

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

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 7, 2020

// EmitErrorEvent emits a failure associated to an error
func EmitErrorEvent(c record.EventRecorder, err error, object runtime.Object) {
if err != nil {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feels a bit odd to have this function take an error as an argument vs checking the error in the place where it originates - is this a pattern we do other places as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's a bit different because in this case the error is the event that we want to send.

On knative they went a bit further, they have now an event object that also implements the error interface.
They have a generated Reconcile that invokes a ReconcileKind which returns an event that may be an error - at least that's how I understood it - so this goes a bit in that direction.

I could check if the err is nil at the source, but it felt safer to do here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My plan for upcoming patches was to centralize the event logic in event.go i.e. to receive all requests events / error notifications from the taskrun/pipelinerun controller in there, and to decide there when to emit what, k8s event and/or cloudevent.

pkg/reconciler/event_test.go Show resolved Hide resolved

err := checkEvents(fr, ts.name, ts.wantEvent)
if err != nil {
t.Errorf(err.Error())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be nice to add some context, e.g. "expected error when blah blah"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The context is added in the error by checkEvents already.
I could add unexpected error when checking for events: %#v", err.Error() but I'm not sure it would add much.

pkg/reconciler/event_test.go Show resolved Hide resolved
afterCondition := tr.Status.GetCondition(apis.ConditionSucceeded)
reconciler.EmitEvent(c.Recorder, beforeCondition, afterCondition, tr)
err := c.updateStatusLabelsAndAnnotations(tr, original)
reconciler.EmitErrorEvent(c.Recorder, err, tr)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

personally i think id rather see an explicit "if err" here vs having EmitErrorEvent handle it, just cuz it doesnt seem consistent with how we usually do error handling - maybe you have a bigger plan around this tho that im not seeing

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I discovered https://github.com/knative/pkg/tree/master/injection#generated-reconciler-responsibilities after I wrote this patch. Maybe I should just try and adopt that :P

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to centralize the logic about what event to send when of what type in events.go, so I included there the check for nil too

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I havent seen https://github.com/knative/pkg/tree/master/injection#generated-reconciler-responsibilities before! Glancing at it I'm not 100% sure what implications it has for this PR, im really glad to see some docs for pkg tho.

I'm trying to centralize the logic about what event to send when of what type in events.go, so I included there the check for nil too

okay, maybe it will make more sense to me as it evolves

test/cancel_test.go Show resolved Hide resolved
afrittoli added a commit to afrittoli/pipeline that referenced this pull request May 13, 2020
Emit additional events:
- Pipeline Start

Emit all events through the events.go module.
Align and simplify the reconcile structure to have clear points
for error handling and emitting events.

Depends on tektoncd#2543
Depends on tektoncd#2526
afrittoli added a commit to afrittoli/pipeline that referenced this pull request May 13, 2020
Emit additional events:
- Pipeline Start

Emit all events through the events.go module.
Align and simplify the reconcile structure to have clear points
for error handling and emitting events.

Depends on tektoncd#2543
Depends on tektoncd#2526
@afrittoli afrittoli added kind/failing-test Categorizes issue or PR as related to a consistently or frequently failing test. kind/feature Categorizes issue or PR as related to a new feature. and removed kind/feature Categorizes issue or PR as related to a new feature. labels May 13, 2020
@tekton-robot
Copy link
Collaborator

This PR cannot be merged: expecting exactly one kind/ label

Available kind/ labels are:

kind/bug: Categorizes issue or PR as related to a bug.
kind/flake: Categorizes issue or PR as related to a flakey test
kind/cleanup: Categorizes issue or PR as related to cleaning up code, process, or technical debt.
kind/design: Categorizes issue or PR as related to design.
kind/documentation: Categorizes issue or PR as related to documentation.
kind/feature: Categorizes issue or PR as related to a new feature.
kind/misc: Categorizes issue or PR as a miscellaneuous one.

1 similar comment
@tekton-robot
Copy link
Collaborator

This PR cannot be merged: expecting exactly one kind/ label

Available kind/ labels are:

kind/bug: Categorizes issue or PR as related to a bug.
kind/flake: Categorizes issue or PR as related to a flakey test
kind/cleanup: Categorizes issue or PR as related to cleaning up code, process, or technical debt.
kind/design: Categorizes issue or PR as related to design.
kind/documentation: Categorizes issue or PR as related to documentation.
kind/feature: Categorizes issue or PR as related to a new feature.
kind/misc: Categorizes issue or PR as a miscellaneuous one.

@afrittoli afrittoli removed the kind/failing-test Categorizes issue or PR as related to a consistently or frequently failing test. label May 13, 2020
@tekton-robot
Copy link
Collaborator

This PR cannot be merged: expecting exactly one kind/ label

Available kind/ labels are:

kind/bug: Categorizes issue or PR as related to a bug.
kind/flake: Categorizes issue or PR as related to a flakey test
kind/cleanup: Categorizes issue or PR as related to cleaning up code, process, or technical debt.
kind/design: Categorizes issue or PR as related to design.
kind/documentation: Categorizes issue or PR as related to documentation.
kind/feature: Categorizes issue or PR as related to a new feature.
kind/misc: Categorizes issue or PR as a miscellaneuous one.

@bobcatfish
Copy link
Collaborator

/lgtm
/kind feature

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label May 13, 2020
@bobcatfish
Copy link
Collaborator

/kind feature

Similarly to how the pipeline controller does, we should emit events
when we fail to update the taskrun.
Events on reconcile error use a dedicated reason.
@afrittoli afrittoli force-pushed the issues/2522_emit_errors branch from 1f411f8 to a8d40e2 Compare May 13, 2020 16:57
@tekton-robot tekton-robot removed the lgtm Indicates that a PR is ready to be merged. label May 13, 2020
@afrittoli
Copy link
Member Author

@bobcatfish I had to rebase because of the stored v1beta1 version :)

@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/taskrun/taskrun.go 75.5% 75.2% -0.2

@afrittoli
Copy link
Member Author

/test pull-tekton-pipeline-integration-tests

@bobcatfish
Copy link
Collaborator

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label May 13, 2020
@tekton-robot tekton-robot merged commit ed4d021 into tektoncd:master May 13, 2020
afrittoli added a commit to afrittoli/pipeline that referenced this pull request May 15, 2020
Emit additional events:
- Pipeline Start

Emit all events through the events.go module.
Align and simplify the reconcile structure to have clear points
for error handling and emitting events.

Depends on tektoncd#2543
Depends on tektoncd#2526
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/feature Categorizes issue or PR as related to a new feature. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants