Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable Workspace Timeout When Running in a Self-Hosted Manner #8528

Closed
lucasvaltl opened this issue Mar 2, 2022 · 8 comments · Fixed by #8576
Closed

Disable Workspace Timeout When Running in a Self-Hosted Manner #8528

lucasvaltl opened this issue Mar 2, 2022 · 8 comments · Fixed by #8576
Assignees
Labels
component: install Terraform installation scripts, helm charts, installer images priority: highest (user impact) Directly user impacting team: delivery Issue belongs to the self-hosted team

Comments

@lucasvaltl
Copy link
Contributor

lucasvaltl commented Mar 2, 2022

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
Copy link
Contributor

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:

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

@corneliusludmann corneliusludmann added the component: install Terraform installation scripts, helm charts, installer images label Mar 2, 2022
@corneliusludmann corneliusludmann added this to the release/2022.03 milestone Mar 2, 2022
@corneliusludmann corneliusludmann added the priority: highest (user impact) Directly user impacting label Mar 3, 2022
@corneliusludmann corneliusludmann moved this from 📓Scheduled to ⚒In Progress in 🚚 Security, Infrastructure, and Delivery Team (SID) Mar 3, 2022
@corneliusludmann corneliusludmann self-assigned this Mar 3, 2022
@kylos101
Copy link
Contributor

kylos101 commented Mar 3, 2022

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
Copy link
Contributor

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
Copy link
Contributor

@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?

@mrsimonemms
Copy link
Contributor

According to https://www.gitpod.io/self-hosted, we're currently advertising all self-hosted instances without any timeout

So, options are:

  1. change the webpage to say "30m or 60m timeout"
  2. remove the timeout entirely (or, if that doesn't work, set to 1 year)

As I'm currently doing #8328, it makes sense to do this now. Personally, I favour option 2

image

Repository owner moved this from ⚒In Progress to ✨Done in 🚚 Security, Infrastructure, and Delivery Team (SID) Apr 6, 2022
@shaoye
Copy link
Contributor

shaoye commented May 26, 2022

According to https://www.gitpod.io/self-hosted, we're currently advertising all self-hosted instances without any timeout

So, options are:

  1. change the webpage to say "30m or 60m timeout"
  2. remove the timeout entirely (or, if that doesn't work, set to 1 year)

As I'm currently doing #8328, it makes sense to do this now. Personally, I favour option 2

image

Hi, it would be great if gitpod adopts option 2 (I think it's a yes according to the latest pricing page).

But currently we are still unable to modify the timeout option (EE licence required https://github.com/gitpod-io/gitpod/blob/main/components/server/ee/src/workspace/gitpod-server-impl.ts#L295)

Do we have an open issue for tracking this? thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: install Terraform installation scripts, helm charts, installer images priority: highest (user impact) Directly user impacting team: delivery Issue belongs to the self-hosted team
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

6 participants
@mrsimonemms @kylos101 @shaoye @lucasvaltl @corneliusludmann and others