Closed
Description
Motivation
- getting rid of old shapes/variance: our code is by now riddled with optional fields (like this:
someField?: string) just because we once in 2018 had a period where we would not set those field. This is an attempt to get rid of those variance to at least have a chance to streamline the code - dead weight: This is about removing old deleted workspaces only: It seems there is no sense in keeping them around
- reduce table size:
- reduce migration times: running a migration on one of the big tables takes ~50mins by now, which does not go well with CD
- reduce storage: This has become a concern, although not a problem, yet
- query time: This is a nice benefit, although not a driver as we don't have problems here for now
Solutions
Add 3rd "purged" state
Currently our Workspace deletion model has two phases:
- soft deleted: A workspace goes into this state either when a) a user deletes it or b) it is garbage collected after a # of days of inactivity. The effect is that is "hidden" from our API, and can easily be reversed e.g. on user request, or inspected in case of abuse, for instance.
- content deleted: A workspace goes into this mode after a certain time being in "soft deleted" state. All workspace contents (backups, logs, etc.) is deleted, and the workspace record is scrubbed from all PII, but the skeleton and main data model stays intact. This is helpful for being able to trace back issues or incidents even after the actual workspace content has been deleted.
This issue proposes to introduce a 3rd state:
- purged: A workspace moves into this state after a certain amount of time being in "content deleted" state. All workspace entries (workspace, instance, prebuild) are completely wiped from the DB.
Remarks
Beyond the pure technical aspect, this affects all of downstream systems as well: We need to make sure that they can handle not getting the total view over all workspaces. 🧘
Metadata
Metadata
Assignees
Type
Projects
Status
Done