Extended.deploymentconfigs with failing hook [Conformance] should get all logs from retried hooks

[danmcp]

https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin_conformance/7944/

https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin_conformance/7944/testReport/junit/(root)/Extended/deploymentconfigs_with_failing_hook__Conformance__should_get_all_logs_from_retried_hooks/

Stacktrace

/data/src/github.com/openshift/origin/test/extended/deployments/deployments.go:589
Expected
    <string>: --> pre: Running hook pod ...
    --> pre: Retrying hook pod (retry #1)
to contain substring
    <string>: no such file or directory
/data/src/github.com/openshift/origin/test/extended/deployments/deployments.go:587

[danmcp]

Note: This was with docker 1.12

Might be related to: https://bugzilla.redhat.com/show_bug.cgi?id=1389474

[ncdc]

I don't think this is related to the bug. There is a change in what's logged between docker 1.10 and 1.12.

1.10

vagrant@f24:~ docker run --name blarg centos:centos7 blarg
exec: "blarg": executable file not found in $PATH
docker: Error response from daemon: Container command not found or does not exist..
vagrant@f24:~ docker logs blarg
exec: "blarg": executable file not found in $PATH
vagrant@f24:~

1.12

vagrant@localhost:~ docker run --name blarg centos:centos7 blarg
/usr/bin/docker-current: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"blarg\": executable file not found in $PATH"%0A.
vagrant@localhost:~ docker logs blarg
vagrant@localhost:~ 

As you can see, 1.12 doesn't log the failure in the container's logs like 1.10 did.

[ironcladlou]

The offender is this deployment test fixture. I'll submit a PR which makes the test case portable across docker versions.

[liggitt]

should we be concerned that a previously working command no longer runs?

[ncdc]

@liggitt it never ran before...

[0xmichalis]

As you can see, 1.12 doesn't log the failure in the container's logs like 1.10 did.

Should we be concerned about this is the correct question

[ncdc]

If you docker inspect, you see the info under .State.Error. I'm not overly concerned, but maybe @mrunalp can weigh in if he considers this a docker regression or not.