Using istio and tekton-pipelines #4722
Unanswered
rkimmel-hv
asked this question in
Q&A
Replies: 1 comment
-
#5067 might fix this |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Right now I have tekton-pipelines installed through the cncf tekton-pipelines chart here https://github.com/cdfoundation/tekton-helm-chart using v0.23.0 and triggers v0.13.0. Currently when my task runs spin up pods the istio-proxy image is replaced by the nop image and everything exits successfully. I am currently trying to change my pipeline version to v0.34.0 using the install process listed in this repo and triggers to v0.19.1. Now when I run a taskrun the istio-proxy container is no longer being replaced by the nop image and the pod hangs around for 45 mins or so before finally exiting. Can I configure something to get the previous behavior or is there some way to exit the istio-proxy container after my task run code completes? I'd prefer NOT to send the /quitquitquit message to istio-proxy if I don't need to.
Edit 1: More digging into this and I think the nop image should still be overriding the istio-proxy image in the task run pod but I'm not sure why this isn't happening. Doesn't look like the pipeline controller pod has any answers either
Edit 2: Comparing versions of taskrun.go from v0.23.0 to current v0.34.0 there seems to be a decent amount of logic in the stopSidecars method. In the old version any non-step containers were considered as sidecars but in the newer version it seems the sidecars must be listed on the taskrun to be considered. Specifically this change
Now while I'd rather not specify istio-proxy sidecars for every single taskRun object I can do this If it will actually work.
Edit 3: This change was added in v0.30.0 with the following commit
2a70aed
Beta Was this translation helpful? Give feedback.
All reactions