Label container status event time

[simwr872]

This is a suggestion related to #15. It would be very nice to have the latest status event time be labeled/annotated on the pod. There is an event produced for this, but events being best-effort (may be dropped) and temporary, a label/annotation could provide this data more reliably (and from pod-state).

Perhaps by adding a label in the pod labeller's setLabel method with the value of status.EventTime:

zeropod/manager/pod_labeller.go

Lines 38 to 43 in 0ee8461

	func (pu *PodLabeller) setLabel(pod *corev1.Pod, status *v1.ContainerStatus) {
	if pod.Labels == nil {
	pod.Labels = map[string]string{}
	}
	pod.Labels[path.Join(StatusLabelKeyPrefix, status.Name)] = status.Phase.String()
	}

What do you think?

[ctrox]

Would be easy enough to add. But may I ask what the use case for that is? Do you want to use this programmatically or just for looking up the last event time with kubectl?

Note that this information is also already available in the metrics.

[simwr872]

Would be easy enough to add. But may I ask what the use case for that is? Do you want to use this programmatically or just for looking up the last event time with kubectl?

Note that this information is also already available in the metrics.

The use case is for tracking resource "usage" (commitment) of pods over time, somewhat precisely. I will try to describe an example that highlights some intricacies:

time	event
0	pod started
3	pod scaled down
6	pod scaled up
8	pod scaled down
9	pod deleted

Assuming that check pointing is enabled, this pod has used resources to the tunes of:

• Between time 0-3, cpu + memory + ephemeral storage.
• Between time 3-6, ephemeral storage + check point storage.
• Between time 6-8, cpu + memory + ephemeral storage.
• Between time 8-9, ephemeral storage + check point storage.

Failing to scrape metrics gauge between time 3-8 would lose the scale down event at time 3, then I would incorrectly have tracked usage for cpu+memory (and not check point storage) between time 3-6. Similar reasoning could be given for events that for any reason were dropped and not produced to the consumers.

With that being said, I am currently watching resources and using now() for changes without an associated timestamp. This works totally fine assuming the delay from etcd is close to zero, which it most likely is. The scale event timestamp would replace the usage of now() for scale events.