Add last_used to user workspaces

[iyannsch]

Is your feature request related to a problem? Please describe.

We are currently writing a functionality to clean up old persistent workspaces that were not used for a longer time. Unfortunately, the workspace, the PCV, and the PV all only feature a CreationDate property but not when the resource was last accessed.
Using this information, we could not only delete workspaces that are older than 2 weeks but also implement more advanced eviction techniques.

Describe the solution you'd like

A new property on the workspace resource providing information about when it was last accessed or mounted to a session.

Describe alternatives you've considered

Only delete based on creation date

Cluster provider

No response

Additional information

No response

[lucas-koehler]

Thanks for the issue!
We discussed with the team and it is definitely a good idea to track the last "use" time of a workspace in its status.
In addition, we propose adding a second property that tracks whether the workspace is currently in use (i.e. a session is running for it). This status property could be named inUse, isUsed or isRunning. It should automatically be reset to false by the operator on session deletion (which also happens when a session times out).

[iyannsch]

Your proposed features would definitely make some processes a bit easier but might also add additional data transfers and load on the system by default.
In our use case (garbage collecting workspaces), we got the K8s API running anyways so we could simply add a check ourselves whether a session exists for a given workspace (assuming stable naming) 👍

[lucas-koehler]

Your proposed features would definitely make some processes a bit easier but might also add additional data transfers and load on the system by default.

You are right that additional data needs to be transmitted. However, I think the impact on system load should be negligible. Updating a isRunning flag would only need status changes once a session is launched and once when it is stopped. Updating a boolean field for this IMO should not have a measurable impact on performance.

In our use case (garbage collecting workspaces), we got the K8s API running anyways so we could simply add a check ourselves whether a session exists for a given workspace (assuming stable naming) 👍

That is good to know :) However, I think long-term we should not depend on internal resources names being stable forever: We do not consider the names of temporary resources (i.e. a Session) as part of the API. Furthermore, names might be different than expected, e.g. due to truncation and/or character replacements.
In contrast information exposed via the resources themselves, and especially the REST service, is.

Another use case is that such a flag allows easy inspection/filtering of running workspaces for admins without writing custom code cross-referencing with running sessions.