Document odd kubectl get output for pods w/ sidecars #1600
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
googlebot
added
the
cla: yes
tekton-robot
added
the
size/S
With the current sidecar implementation `kubectl get pods` will show pods with successful sidecars as Completed but pods with errored sidecars as Error. It looks like the kubectl get pods printer code is just using the status of the last container in the container list as the source of the "Reason" that it prints for a pod ending. Seems a bit janky but ¯\_(ツ)_/¯ I'm documenting the behaviour rather than looking to fix it since there's are existing proposals to improve the sidecar implementation and this appears to simple be a UI/UX issue. The status of the TaskRun that generated the pod has the correct end status regardless of the output from `kubectl get pods`.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dibyom 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 |
tekton-robot
added
the
approved
ghost
deleted the
chmouel
reviewed
Nov 23, 2019
| but an Error when the sidecar exits with an error. This is only apparent when | ||
| using `kubectl` to get the pods of a TaskRun, not when describing the Pod | ||
| using `kubectl describe pod ...` nor when looking at the TaskRun, but can be quite | ||
| confusing. |
There was a problem hiding this comment.
FYI: maybe we want to add that tektoncd-cliwould do the right thing too,
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
With the current sidecar implementation
kubectl get podswill show pods with successful sidecars as Completed but pods with errored sidecars as Error.It looks like the kubectl get pods printer code is just using the status of the last container in the container list as the source of the "Reason" that it prints for a pod ending. Seems a bit janky but ¯_(ツ)_/¯
I'm documenting the behaviour rather than looking to fix it since there's are existing proposals to improve the sidecar implementation and this appears to simple be a UI/UX issue. The status of the TaskRun that generated the pod has the correct end status regardless of the output from
kubectl get pods.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:
cmddir, please updatethe release Task to build and release this image.
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