-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Properly cleanup injected sidecars #5565
Conversation
|
Hi @tomkennedy513. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/ok-to-test |
The following is the coverage report on the affected files.
|
/test check-pr-has-kind-label |
@vdemeester: The specified target(s) for
The following commands are available to trigger optional jobs:
Use In response to this:
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. |
If this does end up having a negative effect, an alternate approach could be relaxing the early exit optimizations (I believe these were added to minimize api calls to retrieve pods) for the stopSidecar method in the case where the |
Chains shouldn't need additional changes. 🎉 For Tekton based provenance we just spit out the status: https://github.com/tektoncd/chains/blob/bc296d1ee1491df7204211cf6d5bd8df9a89c157/pkg/chains/formats/tekton/tekton.go#L34-L37 In-toto is WIP - @chitrangpatel pointed out we aren't capturing sidecars and other fields in the predicate at the moment, but we'll look to populate from the Run status once we support it. |
Sorry for the delay on this @tomkennedy513 - This looks good to me but wanted to see if any of the other @tektoncd/core-maintainers had any opinions on this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your PR! Mostly look good~
pkg/reconciler/taskrun/taskrun.go
Outdated
// do not continue if the TaskSpec had no sidecars | ||
if tr.Status.TaskSpec != nil && len(tr.Status.TaskSpec.Sidecars) == 0 { | ||
return nil | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to delete this considering the change in pkg/pod/status.go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to delete it, but do to the changes in status.go, this check should be sufficient to exit early imo.
/assign @abayer |
The following is the coverage report on the affected files.
|
c2dd68a
to
a5e31a9
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lbernick, XinruZhang 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 |
Injected sidecars are only cleaned up if sidecars are defined in the task spec because of a check that exits early if the TaskRun does not include any sidecars. This breaks users that are running in environments with injected sidecars, but are not defining sidecars in their TaskRuns. This change will remove the early exit condition when there are no sidecars defined on the TaskRun Spec. This will cause the podconvert.StopSidecars method to run every time, properly cleaning up sidecars the TaskRun doesn't know about. Resolves tektoncd#4731
a5e31a9
to
fdf295c
Compare
@lbernick I made those test changes. Thank you for the suggestions! |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this fix. See my comment about the release notes.
/lgtm
if !podconvert.IsSidecarStatusRunning(tr) { | ||
return nil | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test in https://github.com/tektoncd/pipeline/pull/5565/files#diff-6e67e9c647bbe2a08807ff5ccbdd7dc9036df373e56b9774d3996f92ab7ceabaL289 will mark a TaskRun
failed if we fail to stop one of the injected sidecars.
I don't run an environment with istio, so I'm not sure what the best behaviour would be; I think failing the TaskRun
because the injected sidecar could not be stopped seems a bit harsh, but at least it would be aligned with the behaviour we have to sidecars defined in the TaskRun
.
I think it would be worth adding a note to the release notes about this.
You can do that even if the PR is merged once you read this comment, since the release notes will be picked up later by the release automation.
fixes tektoncd#7640 In tektoncd#5565, we started stopping injected sidecars with `nop` in the same way we stop explicitly defined sidecar containers. `MakeTaskRunStatus` was updated to only include explicitly defined sidecars in the `TaskRun` status, rather than just any container in the `TaskRun` pod that doesn't start with `step-`, so while the pod is running, the injected sidecar doesn't show up in the status. However, once the pod has completed and the sidecars are stopped, if the `TaskRun`'s spec contains a sidecar, `updateStoppedSidecarStatus` will be called, and that function's logic for what containers to include in `TaskRun.Status.Sidecars` is still including everything but `step-`-prefixed containers. That should be updated to behave in the same way as `MakeTaskRunStatus`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
fixes #7640 In #5565, we started stopping injected sidecars with `nop` in the same way we stop explicitly defined sidecar containers. `MakeTaskRunStatus` was updated to only include explicitly defined sidecars in the `TaskRun` status, rather than just any container in the `TaskRun` pod that doesn't start with `step-`, so while the pod is running, the injected sidecar doesn't show up in the status. However, once the pod has completed and the sidecars are stopped, if the `TaskRun`'s spec contains a sidecar, `updateStoppedSidecarStatus` will be called, and that function's logic for what containers to include in `TaskRun.Status.Sidecars` is still including everything but `step-`-prefixed containers. That should be updated to behave in the same way as `MakeTaskRunStatus`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
fixes tektoncd#7640 In tektoncd#5565, we started stopping injected sidecars with `nop` in the same way we stop explicitly defined sidecar containers. `MakeTaskRunStatus` was updated to only include explicitly defined sidecars in the `TaskRun` status, rather than just any container in the `TaskRun` pod that doesn't start with `step-`, so while the pod is running, the injected sidecar doesn't show up in the status. However, once the pod has completed and the sidecars are stopped, if the `TaskRun`'s spec contains a sidecar, `updateStoppedSidecarStatus` will be called, and that function's logic for what containers to include in `TaskRun.Status.Sidecars` is still including everything but `step-`-prefixed containers. That should be updated to behave in the same way as `MakeTaskRunStatus`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
fixes #7640 In #5565, we started stopping injected sidecars with `nop` in the same way we stop explicitly defined sidecar containers. `MakeTaskRunStatus` was updated to only include explicitly defined sidecars in the `TaskRun` status, rather than just any container in the `TaskRun` pod that doesn't start with `step-`, so while the pod is running, the injected sidecar doesn't show up in the status. However, once the pod has completed and the sidecars are stopped, if the `TaskRun`'s spec contains a sidecar, `updateStoppedSidecarStatus` will be called, and that function's logic for what containers to include in `TaskRun.Status.Sidecars` is still including everything but `step-`-prefixed containers. That should be updated to behave in the same way as `MakeTaskRunStatus`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
fixes tektoncd#7640 In tektoncd#5565, we started stopping injected sidecars with `nop` in the same way we stop explicitly defined sidecar containers. `MakeTaskRunStatus` was updated to only include explicitly defined sidecars in the `TaskRun` status, rather than just any container in the `TaskRun` pod that doesn't start with `step-`, so while the pod is running, the injected sidecar doesn't show up in the status. However, once the pod has completed and the sidecars are stopped, if the `TaskRun`'s spec contains a sidecar, `updateStoppedSidecarStatus` will be called, and that function's logic for what containers to include in `TaskRun.Status.Sidecars` is still including everything but `step-`-prefixed containers. That should be updated to behave in the same way as `MakeTaskRunStatus`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
Changes
Injected sidecars are only cleaned up if sidecars are defined in the task spec because of a check that exits early if the TaskRun does not include any sidecars. This breaks users that are running in environments with injected sidecars, but are not defining sidecars in their TaskRuns.
This change will remove the early exit condition when there are no sidecars defined on the TaskRun Spec. This will cause the podconvert.StopSidecars method to run every time, properly cleaning up sidecars the TaskRun doesn't know about.
/kind bug
Resolves #4731
Submitter Checklist
functionality, content, code)
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes