I'm thinking of a few situations where it might be desirable to keep a workspace in Coder, but ensure that Coder will not take any actions on it. Meaning Coder wouldn't stop or start it based on schedule, would disable the start button, and would make the workspace undeletable for as long as the workspace is in this "frozen" state. As part of freezing a workspace, the stop lifecycle would be run first to turn down compute resources (or this could be an option and by default leave everything its current state). I'm mostly thinking about this from the POV of an admin, but there may be cases where an end-user may desire this.

Possible Use-Cases

1. Extended leave - We could ensure that when a person goes on leave, that their data will not be deleted by inactivity deletion automation and clean up the workspace's compute resources. Once they return, unfreezing their workspaces will allow them to return to being controlled by a start/stop schedule. In many cases, our engineers take leave in chunks larger than our deletion window.
2. Terminations - There may be scenarios where an employee leaves abruptly and for security or HR reasons, we want to retain their data for a period. Freezing a workspace would prevent the SCIM provisioned user deletion event from cleaning up the workspace.
3. Maintenance - I haven't thought too much about this one, but suppose I have an EBS volume defined as part of a template and I want to expand the size. I'd rather apply this change through a script so that I can expand the filesystem on the volume at the same time. During this process, I would want to ensure that Coder cannot make changes/run Terraform against the workspaces using this template. I could freeze and unfreeze to accomplish this. This is a contrived example, but this is the spirit of what I'm talking about.