feat(controller): Add last hit timestamp to memoization caches

[terrytangyuan]

This is the first step mentioned in #5406.

Controller to manage GC of configmaps based on this timestamp will be added as a follow-up PR later as it requires additional work. We can start using this timestamp in our cluster and experiment with different options in the meantime (hopefully gather more experience and feedback on GC strategies through the process). Our immediate need is to have a better way to tell whether a cache is still useful.

cc @simster7 Could you take a look when you get a chance?

Signed-off-by: terrytangyuan terrytangyuan@gmail.com

Checklist:

• My organization is added to USERS.md.

[simster7]

We surely also "hit" an entry when we write to it no?

[terrytangyuan]

We surely also "hit" an entry when we write to it no?

I initially wanted to differentiate from it but I just added it anyways since this differentiation would introduce unnecessary logic in downstream apps (for GC mechanism). Please take another look.

[simster7]

I wonder what the utility of creation timestamp is now that we introduce last hit timestamp... perhaps maxAge should always reference lastHitTimestamp instead, although this would break some user expecations about how maxAge works....

What do you think?

[terrytangyuan]

This is only when it's firstly saved. When the entry is actually hit/loaded every time, the LastHitTimestamp would change. I think maxAge should stick with CreationTimestamp as the expectation for age is after something is initially born/created. Interesting analysis can be done by utilizing both timestamps, e.g. the cache is very old but still being used so maybe it's time to delete/refresh it?

[simster7]

Interesting analysis can be done by utilizing both timestamps, e.g. the cache is very old but still being used so maybe it's time to delete/refresh it?

Yeah I agree, this is good potential. Out of scope for this PR though