Disable Workspace Timeout When Running in a Self-Hosted Manner

[lucasvaltl]

Is your feature request related to a problem? Please describe

I'm having the issue of workspaces timing out and thus shutting down even though I still want to use it.

Describe the behaviour you'd like

Interactive way to change the timeout of a workspace to allow it to run continuously even after a script has finished and/or there is no user input/activity.

Describe alternatives you've considered

Put a sleep at the end of the script, which is more of a hack

Additional context

Connecting to the workspace via SSH & using self-hosted Gitpod

[corneliusludmann]

A pretty simple fix would be to add a config value to the installer that allows setting the timeout timespan. With that, customers can set an outrageous amount of time as timeout (let's say 1 year or so).

Since the extending of timeouts is an enterprise feature, the values are set here:

gitpod/components/server/ee/src/user/user-service.ts

Lines 25 to 37 in 5b74af7

	async getDefaultWorkspaceTimeout(user: User, date: Date): Promise<WorkspaceTimeoutDuration> {
	if (this.config.enablePayment) {
	// the SaaS case
	return this.eligibilityService.getDefaultWorkspaceTimeout(user, date);
	}
	// the self-hosted case
	if (!this.licenseEvaluator.isEnabled(Feature.FeatureSetTimeout)) {
	return "30m";
	}
	return "60m";
	}

The 60m in line 36 is the default that is used for enterprise customers with a proper license.

In the installer config, I would propose to make clear that it's an enterprise feature that does not have any effect without a proper license (unless we decide that this should not be an enterprise feature anymore for some reason), e.g. by adding a section enterpriseFeatures:

# changing values of enterprise features are only available with a proper license
enterpriseFeatures:
  defaultWorkspaceTimeout: 8760h   # 1 year

[kylos101]

I'm having the issue of workspaces timing out and thus shutting down even though I still want to use it.

@lucasvaltl which timeout are you referring?

1. The inactivity timeout (which is 1 hour, and depending on your plan, can be extended in VS Code by clicking a toggle in the bottom right, to 3 hours)?
2. The workspace total runtime timeout (36h)? After this timespan, we stop workloads, even if actively being used. Introduced here as part of the installer config.
3. Something else?

CC: @corneliusludmann

[corneliusludmann]

Thanks for your comment, @kylos101. Didn't know that something like the workspace total runtime timeout exists. As far as I know, it's about the inactivity timeout. However, when they want to run workspaces longer than 36 hours, we need to make the total runtime timeout configurable as well.

@lucasvaltl: Could you take care that someone clarifies with the customer the actual use case and how long the workspaces actually need to run?

[corneliusludmann]

@charlevelz: Thanks for your feedback. Could you add more details about your use case? Gitpod is designed to run ephemeral workspaces for software developing tasks. When you say that you're testing services, how exactly do you use Gitpod?