-
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
PipelineRun hangs in Pending state #1068
Comments
Oh noes, I'm seeing the same thing :(((( Not sure how this slipped by our tests but I guess we'll find out!!
I wanted to make a new 0.5.1 release with #1061 but we should fix this first! I'm guessing this is a bug with #1007 |
Awesome! yea I found if you create a second step that links or depends on the first it'll created a PVC and enable the pipeline to run. |
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.
Sorry again about this @castlemilk and thanks for the quick report! I've created https://github.com/tektoncd/pipeline/tree/release-v0.5.1 with our 2 bug fixes and I'll make 0.5.1 release first thing monday EST :) 🙏 |
Okay https://github.com/tektoncd/pipeline/releases/tag/v0.5.1 should have this fixed! (It's back to making an extra PVC unfortunately, but we'll have a better fix for that via #937 hopefully!) Thanks again for the report and your patience @castlemilk ! ❤️ |
Expected Behavior
Pipeline should run singular task, as it would in pre v0.5.0
Actual Behavior
Pipeline stun in
Pending
state, waiting for aPVC
to be provisioned which hasn't been created by the controller.Logs will be observed warning:
and
Steps to Reproduce the Problem
deploy the following pipeline:
The
Pod
for running the pipeline will be created, but without aPVC
, consequently thePod
is stuck in aPending
state, waiting for a referencedPVC
, which hasn't been created by the tekton-controller.The full pipeline defined here then works, which contains multiple tasks in one pipeline
Tekton Version - v0.5.0
Kubernetes Versio - 1.13
The text was updated successfully, but these errors were encountered: