If no resources are linked, don't make a PVC 🗑️ #1007
Conversation
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
tekton-robot
added
approved
dlorenc
added
cla: yes
|
A Googler has manually verified that the CLAs look good. (Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.) ℹ️ Googlers: Go here for more info. |
|
/lgtm |
When ouputs of a Task are linked to the inputs of another we create a PVC (or use a bucket) to share the data between executing Tasks. However we were doing this even when no Resources were linked! Now we only do it when we need to. Co-authored-by: Christie Wilson <bobcatfish@gmail.com> Fixes: tektoncd#937
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
googlebot
added
cla: no
and removed
cla: yes
dlorenc
added
cla: yes
|
A Googler has manually verified that the CLAs look good. (Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.) ℹ️ Googlers: Go here for more info. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dlorenc, 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 |
In tektoncd#1007 @dlorenc and I tried to fix the case where a PVC wasn't needed for output -> input linking and it was being created anyway. What we forgot to do was check to see where that PVC was being mounted. It turns out that if a TaskRun has an output and is created by a PipelineRun (this is checked via the owner reference), the TaskRun assumes it needs to mount the volume and further adds containers to copy the output data to the (possibly) non-existent PVC. @castlemilk caught this problem in tektoncd#1068. The real fix here is probably going to involve an interface change b/c we can't assume that just being owned by a PipelineRun means that a linking PVC is going to be involved. This commit is a terrible and probably race condition hack to make it so that if the PVC the TaskRun is expecting doesn't exist, it doesn't attempt to add containers that will copy data to it. Making the hack even worse is that instead of adding more actual unit tests, I updated the test to run all the existing unit tests twice, once with this PVC existing and once with it not, and I manipulated the test so that in the case where it doesn't exist, the expected outcome is different. This is a terrible way to write tests and I hope we either don't merge this or we fix it quickly afterward. @dlorenc and I are going to work on a better fix tomorrow. I also modified our end to end PipelineRun test to include an output resource so we could reproduce the issue that @castlemilk reported.
In tektoncd#1007 @dlorenc and I tried to fix the case where a PVC wasn't needed for output -> input linking and it was being created anyway. What we forgot to do was check to see where that PVC was being mounted. It turns out that if a TaskRun has an output and is created by a PipelineRun (this is checked via the owner reference), the TaskRun assumes it needs to mount the volume and further adds containers to copy the output data to the (possibly) non-existent PVC. @castlemilk caught this problem in tektoncd#1068. The real fix here is probably going to involve an interface change b/c we can't assume that just being owned by a PipelineRun means that a linking PVC is going to be involved. This commit is a terrible and probably race condition hack to make it so that if the PVC the TaskRun is expecting doesn't exist, it doesn't attempt to add containers that will copy data to it. Making the hack even worse is that instead of adding more actual unit tests, I updated the test to run all the existing unit tests twice, once with this PVC existing and once with it not, and I manipulated the test so that in the case where it doesn't exist, the expected outcome is different. This is a terrible way to write tests and I hope we either don't merge this or we fix it quickly afterward. @dlorenc and I are going to work on a better fix tomorrow. I also modified our end to end PipelineRun test to include an output resource so we could reproduce the issue that @castlemilk reported.
We only need to make a PVC if a Pipeline contains tasks that declare Output resources of the allowed types. This PR changges our detection to only create a PVC under those conditions. This was originally attempted in tektoncd#1007 and then subsequently rolled back in tektoncd#1071. I *think* this one gets the logic correct :) Co-authored-by: Christie Wilson <bobcatfish@gmail.com> Fixes: tektoncd#937
We only need to make a PVC if a Pipeline contains tasks that declare Output resources of the allowed types. This PR changges our detection to only create a PVC under those conditions. This was originally attempted in tektoncd#1007 and then subsequently rolled back in tektoncd#1071. I *think* this one gets the logic correct :) Co-authored-by: Christie Wilson <bobcatfish@gmail.com> Fixes: tektoncd#937
We only need to make a PVC if a Pipeline contains tasks that declare Output resources of the allowed types. This PR changges our detection to only create a PVC under those conditions. This was originally attempted in tektoncd#1007 and then subsequently rolled back in tektoncd#1071. I *think* this one gets the logic correct :) Co-authored-by: Christie Wilson <bobcatfish@gmail.com> Fixes: tektoncd#937
We only need to make a PVC if a Pipeline contains tasks that declare Output resources of the allowed types. This PR changges our detection to only create a PVC under those conditions. This was originally attempted in #1007 and then subsequently rolled back in #1071. I *think* this one gets the logic correct :) Co-authored-by: Christie Wilson <bobcatfish@gmail.com> Fixes: #937
Changes
When outputs of a Task are linked to the inputs of another we create a
PVC (or use a bucket) to share the data between executing Tasks. However
we were doing this even when no Resources were linked! Now we only do it
when we need to.
Co-authored-by: Christie Wilson bobcatfish@gmail.com
Fixes: #937
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
Release Notes
Fixed an issue that caused PVCs to be created in some PipelineRuns when they were not necessary.