NO FailedPostStartHook Error Message After Upgrade to 1.7.8

[lovejoy]

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

What happened:
NO FailedPostStartHook Error Message After Upgrade to 1.7.8
When we use 1.6.3 , We can get message like Error syncing pod, skipping: failed to "StartContainer" for "xxxx" with PostStart handler: command '/xxxxxx' exited with 1: Hook do errexit, this is stderr : "PostStart Hook Failed" From Event, But After Upgrade to 1.7.8 ,the FailedPostStartHook Event always have no message

What you expected to happen:
we need the message to find out the poststarthook failed reason

How to reproduce it (as minimally and precisely as possible):
Use PostStartHook And Fail It

Anything else we need to know?:

a02f10f
pkg/kubelet/kuberuntime/kuberuntime_container.go
line 123 ,dont delete it

Environment:

• Kubernetes version (use kubectl version):
  Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.8", GitCommit:"bc6162cc70b4a39a7f39391564e0dd0be60b39e9", GitTreeState:"clean", BuildDate:"2017-10-05T06:54:19Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.8", GitCommit:"bc6162cc70b4a39a7f39391564e0dd0be60b39e9", GitTreeState:"clean", BuildDate:"2017-10-05T06:35:40Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):CentOS Linux 7 (Core)
• Kernel (e.g. uname -a):4.13.7-1.el7.elrepo.x86_64
• Install tools:
• Others:

[lovejoy]

/area kubelet
/sig node

[lovejoy]

@derekwaynecarr

[xiangpengzhao]

I think this was fixed from 1.8.
see: 9fcc25d

[lovejoy]

@xiangpengzhao
the error message is in handlerErr ,so 9fcc25d didnot fix this

[OJezu]

I've just updated to kubernetes 1.8 and still no error message in kubectl describe pod <pod>

However, I've never seen it there, as I've been using k8s for a few days, some of which were spent on searching how to debug hooks...

Anyway client and server version:

Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"0b9efaeb34a2fc51ff8e4d34ad9bc6375459c4a4", GitTreeState:"dirty", BuildDate:"2017-10-17T15:09:55Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Server is running as a part of minikube

[xiangpengzhao]

@lovejoy @OJezu thanks for pointing it out! I send PR #54739. PTAL.

[lovejoy]

@xiangpengzhao We also require the error message included in the Event， Would you please add it?

[xiangpengzhao]

Seems like the handlerErr is already included in the msg according to m.runner.Run implementation.

https://github.com/kubernetes/kubernetes/blob/3dfaa086b39ac18ae44dfc1614350f7eb1565fa4/pkg/kubelet/kuberuntime/kuberuntime_container.go#L161

[lovejoy]

the m.runner.Run in master seems same as release-1.7 ,And I found the msg is empty in release-1.7，so the handlerErr may not included in msg.

[xiangpengzhao]

ping @sjenning and @derekwaynecarr for confirmation. thanks!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[lovejoy]

JUST FOR SOMEBODY WHO CARE ABOUT THE PostStartHook Event Message
"the msg is empty " have really already been fixed in #56959
It's in release 1.7.12 but it seems the release note didn't mention this