Fix all Age, LastSeen, and FirstSeen displays

[Nokel81]

• Sorting based on non-changing values without using Date.now()

• Displaying base on "mobx-utils".now() with some optimization for
  updates of very long durations

• Deprecating KubeObject.getTimeDiffFromNow and KubeObject.getAge
  methods as they are not reactive

• Export ReactiveDuration to the extension API.

Signed-off-by: Sebastian Malton sebastian@malton.name

[jim-docker]

Looks like it's too reactive now:

Screen.Recording.2022-03-15.at.3.04.04.PM.mov

Also noticed Last seen time for newly created pod of 52y, but might be an old bug.

[Nokel81]

newly created pod of 52y

Sounds like the unix epoch

Looks like it's too reactive now:

Do you think it should be slower then? Because those updates are all synchronized (namely they all react against the same observable clock instance)

[jim-docker]

newly created pod of 52y

Sounds like the unix epoch

Looks like it's too reactive now:

Do you think it should be slower then? Because those updates are all synchronized (namely they all react against the same observable clock instance)

Updating the item list every second seems too much(?) I guess if it's not making kube api calls every update it's good.

[Nokel81]

Updating the item list every second seems too much(?) I guess if it's not making kube api calls every update it's good.

For something like age I think updating every second (while seconds are displayed) and then only updating every minute is fine.

And yes this is a completely local calculation. It is based on the metadata.creationTimestamp field which should never change.

[jim-docker]

Nice work.
The sort direction for Age seems backwards to me:

Shouldn't the values go from small to large reading down the list for this indicator?

[jim-docker]

Suggested change

	<p>Prefered version ({crd.getGroup()}/{version.name}) is not served</p>
	<p>Preferred version ({crd.getGroup()}/{version.name}) is not served</p>

[Nokel81]

Shouldn't the values go from small to large reading down the list for this indicator?

I guess it depends on what you think the default sorting means. I took it as the chevron points in the direction of sort from smallest to largest.

So an up chevron would mean that the largest age is near the top of the table.

[jakolehm]

IMHO we need to tweak formatDuration (or use other formatter) now that we update/compute the duration. Updating things like 2m3s every second will be annoying. My suggestion is to drop seconds completely when over 1m and then update duration only once per minute.

[jakolehm]

Just realized that current formatDuration mimics kubectl output. Maybe it's ok to keep using that.

[Nokel81]

I can tweak it if you like...

I could slow down the updates to every 5s if you think it is too fast, and thus distracting.

[jakolehm]

Not sure if updating age/duration every second for 10 minutes is a good idea but we can tweak it after we get some real usage.

[jim-docker]

Shouldn't the values go from small to large reading down the list for this indicator?

I guess it depends on what you think the default sorting means. I took it as the chevron points in the direction of sort from smallest to largest.

So an up chevron would mean that the largest age is near the top of the table.

I agree with how you interpret what it should mean but I don't think that is consistent with other fields. For names the chevron pointing up has the "smallest" name at the top.

I assumed how it works is chevron up means ascending, and since the natural direction for a list is downward, then ascending means the values go up as you read the list (down). But I agree it seems more natural for the chevron to point in the direction of the ordering in the list.

Anyway I think what you have here for age is inconsistent with other columns (like restarts on pods)

[Nokel81]

Anyway I think what you have here for age is inconsistent with other columns (like restarts on pods)

That is very convincing, we should be consistent with out UI. Will change.

[jim-docker]

Still want it for 5.4.3? I guess we can decide when we go to release 5.4.3. I think it should be 5.5, since it changes behaviour (updates every second), which may be a bit surprising to see in a patch.

[Nokel81]

There seems to be more consensus for it being 5.5 so let's do that.