k8s: Age field to pod proto

[smonero]

Add an age field representing a human friendly string that is the time elapsed since CreationTimestamp.

Description

This might be a bad idea, if it is, I'll close this PR but wanted to put this out as an attempt at fixing our problem.

In the k8s dash we want to display the age. Normally we would construct this from the timestamp. However, it might be easier to just do it like this, until protobufjs/protobuf.js#1495 is merged or something similar is done.

If it turns out this is a good idea, then I'll make a follow-up PR for doing the same thing in deployment, which can also use an Age field (similar to how lyftkube does it).

Testing Performed

local

GitHub Issue

Fixes #

TODOs

[rithujohn191]

So is the plan to have start time and age as separate fields in Pod? Feels redundant to have both

[smonero]

I can remove start time for now.

CreationTimestamp comment in types.go:
// CreationTimestamp is a timestamp representing the server time when this object was
// created. It is not guaranteed to be set in happens-before order across separate operations.
// Clients may not set this value. It is represented in RFC3339 form and is in UTC.
//
// Populated by the system.
// Read-only.
// Null for lists.
// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

StartTime comment from types.go:
// RFC 3339 date and time at which the object was acknowledged by the Kubelet.
// This is before the Kubelet pulled the container image(s) for the pod.

[rithujohn191]

In the local testing performed did you have a chance to run through the delete pod flow to ensure the serialization is done correctly?

[danielhochman]

the twitter API used to do this, they would send the timestamp across in three formats. from memory it was something like:

• millis since epoch (created_at_ms), e.g. 12323829382
• ISO8601 (created_at) e.g. 2001-02-01T13:43:32Z
• human readable (created_at_human or created_at_relative) e.g. 3h ago

they moved away from it and only send one timestamp now because the human readable version goes out-of-date. on the twitter app they want it to say 10s ago, then 30s ago, then 5 min ago if you look at the tweet several times, rather than whatever the age was when the API call was made.

for our use case it's probably fine to add the human readable representation if we can't reasonably fix the serialization bug, knowing that we may end up having to pay the deprecation cost later.

if we do decide to keep this i would keep the existing field (since we should still use it in the future and fix the bug) and call the new field <existing_field_name>_human i.e. start_time_human rather than age.

[github-actions]

This PR has been marked as stale after 7 or more days of inactivity. Please have a maintainer add the on hold label if this PR should remain open. If there is no further activity or the on hold label is not added, this PR will be closed in 3 days.

[smonero]

closing this for now, going to open one shortly with a different approach