Skip to content

Give new workspaces more resources #11144

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

Closed
Furisto opened this issue Jul 5, 2022 · 4 comments
Closed

Give new workspaces more resources #11144

Furisto opened this issue Jul 5, 2022 · 4 comments
Labels
team: workspace Issue belongs to the Workspace team

Comments

@Furisto
Copy link
Member

Furisto commented Jul 5, 2022

Is your feature request related to a problem? Please describe

The experience of opening a new workspaces can be painful because setup tasks are running. Users have to wait until they can start working because not enough resources are available to fulfill all requests.

Describe the behaviour you'd like

Give new workspaces a higher priority (maybe use the already existing Qos attribute) during resource distribution.

@Furisto Furisto added the team: workspace Issue belongs to the Workspace team label Jul 5, 2022
@Furisto Furisto moved this to Scheduled in 🌌 Workspace Team Jul 5, 2022
@atduarte
Copy link
Contributor

atduarte commented Jul 5, 2022

What alternatives were considered and discussed? Would ensure that the IDE has enough resources during that time be sufficient?

@aledbf
Copy link
Member

aledbf commented Jul 5, 2022

I think this would be unfair to the other workspaces running in the node. I could even abuse that running tasks knowing that I have more CPU

@kylos101
Copy link
Contributor

kylos101 commented Jul 5, 2022

👋 @Furisto thank you for creating this issue. @aledbf and I tested this recently with gen47 and gen51, and observed the same trend. It's an existing/old problem, I think, generally encountered when workspaces (usually monorepos) try to run too much.

We should talk more before scheduling this issue, I am going to move back to our inbox for now.

For example, there may be other ways to solve this problem. Perhaps we could do a combination of things:

  • introduce larger workspace classes
  • increase the lower limits of the existing XL workspace class
  • show users a "gauge" for their various resources and rely on them to tune their respective workloads
  • proactively notify users when they're using excessive resources, to either tune their repo or use a larger workspace class (I think @atduarte recently created an issue for this idea)

@kylos101 kylos101 removed the status in 🌌 Workspace Team Jul 5, 2022
@atduarte
Copy link
Contributor

In an effort to keep the Inbox tidy and with only actionable work, I will close this in favour of #10861 as the desired outcome is similar. Feel free to reopen if you disagree.

@atduarte atduarte closed this as not planned Won't fix, can't repro, duplicate, stale Jul 25, 2022
@atduarte atduarte moved this to Awaiting Deployment in 🌌 Workspace Team Jul 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team: workspace Issue belongs to the Workspace team
Projects
None yet
Development

No branches or pull requests

4 participants