Workspace instances should have a max lifetime

[csweichel]

Is your feature request related to a problem? Please describe

At the moment workspace instances can run an indefinite amount of time. This causes operational issues during cluster updates, and is seldom desired behaviour considering the ephemeral nature of Gitpod workspaces.

Describe the behaviour you'd like

Workspace instances should have a maximum lifespan after which they're shut down automatically. This shall be very large, 72 hours, so as to not impact users regularly.

Note: this affects workspace instances, i.e. your workspace would shut down and could be restarted immediately, much like a regular timeout.

Describe alternatives you've considered

Instead of making this general behaviour we could handle this on a case-by-case basis, but that makes Gitpod's behaviour less predictable and harder to communicate.

[atduarte]

This is lifespan must be very large, e.g. two days (48h)

Just wanted to reiterate this as we don't want to invalidate Data Science use cases. I feel 2 days is reasonable [1] but believe we should research further.

[atduarte]

After some research I believe 2 days is reasonable, and we could go with 36 hours.

First, looking at the SaaS data from this year, we only had 0.00035% of the workspace instances living for more than 48 hours. If we were to set the max lifetime to 36h it would impact 0.0005%. And 24h, 0.017%.

Percentile	Minutes
.5	17
.9	121
.999	769
.99999	3829

Additionally, from what I gathered most data science workloads would perfectly (!) fit in the 36h timeframe. In the cases it does not probably Gitpod SaaS is not appropriate, and better workspace resources or parallelisation is needed.

---

What would the experience be in those 0.00035% cases? Could we send an email to the user before the workspace is shutdown?

[kylos101]

@jldec hey there 👋 ,

@atduarte brings up an interesting point Re: setting user expectations if we forcibly stop a workspace due to it exceeding the max lifetime.

Notifying the end-user somehow feels like a feature that would live in a WebApp cluster. WDYT?

@atduarte in the meantime, I am going to schedule this, so that we get a configurable 3 day limit set.

[princerachit]

Note: this affects workspace instances, i.e. your workspace would shut down and could be restarted immediately, much like a regular timeout.

Which component should trigger the shutdown? Can we inject some code in the workspace it self to shutdown or do you propose to do this via ws-daemon or ws-manager?

[csweichel]

it would be ws-manager - we already have timeouting behaviour for various workspace phases. This would basically add one for RUNNING (next to and independently of the heartbeating mechanism)