-
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
testSideCar is failing #1253
Comments
/assign |
Sidecar tests were failing on our CI when using the busybox images, switching it to ubuntu image 'fix' it. I tried a few other way to fix it properly (change the paths, change loop to sleep infinity etc...) with no success. Closes tektoncd#1253
Sidecar tests were failing on our CI when using the busybox images, switching it to ubuntu image 'fix' it. I tried a few other way to fix it properly (change the paths, change loop to sleep infinity etc...) with no success. Closes #1253
Sidecar tests were failing on our CI when using the busybox images, switching it to ubuntu image 'fix' it. I tried a few other way to fix it properly (change the paths, change loop to sleep infinity etc...) with no success. Closes tektoncd#1253
hm @chmouel maybe we should leave this open to continue to investigate and find the root cause? sounds like we're still not completely sure why this is happening? (probably would be hard for non-open shift folks to investigate tho so I'll leave it up to you!) |
@bobcatfish sounds good, ill dig into it a bit more! (i don't think i have the rights to reopen it tho) |
So i spent some more time on this and there is definitively something funky going on in there. If I use the ubuntu image in the sidecar test and run the tests : % git reset --hard
HEAD is now at 39505213 Add comments about the two scenarios for upgrade tests
% go test -failfast -v -count=1 -tags=e2e -ldflags '-X github.com/tektoncd/pipeline/test.missingKoFatal=false' ./test -timeout=20m --kubeconfig $KUBECONFIG -run TestSidecarTaskSupport
=== RUN TestSidecarTaskSupport
2019-09-02T13:11:07.920+0200 info logging/config.go:43 Successfully created the logger. {"knative.dev/jsonconfig": "{\n\t \"level\": \"info\",\n\t \"encoding\": \"console\",\n\t \"outputPaths\": [\"stdout\"],\n\t \"errorOutputPaths\": [\"stderr\"],\n\t \"encoderConfig\": {\n\t \"timeKey\": \"ts\",\n\t \"messageKey\": \"message\",\n\t \"levelKey\": \"level\",\n\t \"nameKey\": \"logger\",\n\t \"callerKey\": \"caller\",\n\t \"messageKey\": \"msg\",\n\t \"stacktraceKey\": \"stacktrace\",\n\t \"lineEnding\": \"\",\n\t \"levelEncoder\": \"\",\n\t \"timeEncoder\": \"iso8601\",\n\t \"durationEncoder\": \"\",\n\t \"callerEncoder\": \"\"\n\t }\n\t}"}
2019-09-02T13:11:07.920+0200 info logging/config.go:43 Logging level set to info
2019-09-02T13:11:07.921+0200 warn logging/config.go:45 Fetch GitHub commit ID from kodata failed: "KO_DATA_PATH" does not exist or is empty
=== RUN TestSidecarTaskSupport/A_sidecar_that_runs_forever_is_terminated_when_Steps_complete
=== RUN TestSidecarTaskSupport/A_sidecar_that_terminates_early_does_not_cause_problems_running_Steps
--- PASS: TestSidecarTaskSupport (30.79s)
init_test.go:113: Create namespace arendelle-4vpzh to deploy to
init_test.go:125: Verify SA "default" is created in namespace "arendelle-4vpzh"
--- PASS: TestSidecarTaskSupport/A_sidecar_that_runs_forever_is_terminated_when_Steps_complete (14.71s)
sidecar_test.go:84: Creating Task "sidecar-test-task-0"
sidecar_test.go:89: Creating TaskRun "sidecar-test-task-run-0"
--- PASS: TestSidecarTaskSupport/A_sidecar_that_terminates_early_does_not_cause_problems_running_Steps (15.59s)
sidecar_test.go:84: Creating Task "sidecar-test-task-1"
sidecar_test.go:89: Creating TaskRun "sidecar-test-task-run-1"
PASS
Using kubeconfig at `/Users/chmouel/.kube/config.os4` with cluster ``
ok github.com/tektoncd/pipeline/test 30.822s
Now using project "arendelle-4vpzh" on server "https://api.chmouelx.devcluster.openshift.com:6443". test run fine and I see the image used being the ubuntu one :
Now let's change it back to busybox as previously commited and run the test :
It's failing not being able to launch a shell
looking at the pod created it weirdly didn't use the
Trying to compare on minikube, the tests do succeed :
but it still use
This is quite surprising, being was able to launch a
So well, i am more confused than before about what's going on, the questions would be :
|
I think I figured out the issue :
https://github.com/tektoncd/pipeline/blame/master/docs/developers/README.md#L183-L187
so the pod gets restarted with the nop image and the previous entrypoint and then fails (as
|
Hm, it looks like the ubuntu container isn't actually running at all. It starts and stops in the same second and running
I'm surprised this isn't exiting with an error status, but it at least explains why ubuntu isn't being replaced with the nop image - it exits immediately on its own so the taskrun controller doesn't need to stop the sidecar. In regards (4) - it's not possible to update a container's So I wonder if the fix might be to consider any "Terminated" status of the sidecar as a successful exit, regardless of Reason. I'll make a PR that puts back the busybox images and updates the test. Then, @chmouel, if you have time to try it out on OpenShift that would be much appreciated! |
@sbwsg yes you are right! this is indeed weird, our CI wil run this on whenever this gets merged, thanks, |
Fixes #1253 When a sidecar is forcefully exited by the taskrun controller it may error out. This happens because the sidecar is terminated by having its image field rewritten to be tekton's nop container. The nop container is bare bones and probably doesnt contain the entrypoint command configured for the sidecar. When this occurs the container will exit with an error of some kind. On GKE this error's Reason is "ContainerCannotRun" but on MiniShift/OpenShift the error Reason is "Error". The sidecar e2e test previously required a termination Reason of "ContainerCannotRun" or "Completed" but this appears to be too rigid. Instead the test now considers a sidecar that has been terminated for any reason to be a success.
…ustom base image
testSideCar
test is failing on our CI based on openshift. I am not really sure if it's an openshift issue or a test issue.Expected Behavior
Working tests
Actual Behavior
events :
Steps to Reproduce the Problem
Additional Info
The text was updated successfully, but these errors were encountered: