UPSTREAM: 47462: strip container id from events

[derekwaynecarr]

xref kubernetes/kubernetes#47462

fixes creation of distinct events in etcd for unhealthy pods.

[derekwaynecarr]

/cc @eparis

[sjenning]

[merge][severity:blocker]

[sjenning]

[merge][severity:blocker]

[eparis]

come on, rosie!

[openshift-bot]

Evaluated for origin merge up to c514c83

[openshift-bot]

[Test]ing while waiting on the merge queue

[openshift-bot]

Evaluated for origin test up to c514c83

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2400/) (Base Commit: b9d68cb) (PR Branch Commit: c514c83)

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin/1046/) (Base Commit: b70d790) (PR Branch Commit: c514c83) (Extended Tests: blocker) (Image: devenv-rhel7_6378)

[smarterclayton]

Is this output new in this PR:

  9m	9m	1	kubelet, localhost	spec.containers{router}	Normal	Created		Created container with id 58aaeddf4408ea6f02424239828f680a8d103dd18298022c25d8a2f0b0a54144
  8m	8m	1	kubelet, localhost	spec.containers{router}	Normal	Killing		Killing container with id docker://58aaeddf4408ea6f02424239828f680a8d103dd18298022c25d8a2f0b0a54144:pod "router-5-zg7rt_default(e2b187d6-561c-11e7-94cc-080027893417)" container "router" is unhealthy, it will be killed and re-created.
  8m	2m	3	kubelet, localhost	spec.containers{router}	Normal	Created		(events with common reason combined)
  23m	2m	12	kubelet, localhost	spec.containers{router}	Normal	Pulled		Container image "openshift/origin-haproxy-router:v3.6.0-alpha.2" already present on machine
  8m	2m	3	kubelet, localhost	spec.containers{router}	Normal	Started		(events with common reason combined)
  8m	2m	3	kubelet, localhost	spec.containers{router}	Normal	Killing		(events with common reason combined)

? The message for common reason is very confusing.

[sjenning]

@smarterclayton There is a bug in EventAggregatorByReasonMessageFunc(). We need to pick kubernetes/kubernetes#46034 as well.

[akostadinov]

So how does user know when some property, like bandwidth is unparsable and pod stays in ContainerCreating forever? Perhaps this is not a big deal in Kubernetes but looks like a no-go for OpenShift as far as I can see.

FYI https://bugzilla.redhat.com/show_bug.cgi?id=1474274

[derekwaynecarr]

@akostadinov - for bandwidth errors, those should be caught in validation. the fact that it is done in annotations and is not a proper resource managed in the core yet leaves this as an advanced use case. if openshift wants to carry special validation code to check those annotations, we can explore the solution that way, but a pod that fails validation should never land on a node.