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

Set workspace class based on user preference #11313

Merged
merged 7 commits into from
Jul 21, 2022
Merged

Set workspace class based on user preference #11313

merged 7 commits into from
Jul 21, 2022

Conversation

Furisto
Copy link
Member

@Furisto Furisto commented Jul 12, 2022

Description

This PR allows user to select their preferred workspace class and start a workspace with it. The feature is hidden behind a feature flag which is segmented to only activate the feature for members of gitpod. This means that WebApp can deploy this feature without having to wait for team workspace to configure the new workspace classes in the workspace clusters.

Currently there are 4 workspace classes that are supported:

  • default
  • gitpod-internal-xl
  • g1-standard
  • g1-large

Default and gitpod-internal-xl are the old internal workspace classes that will be eventually removed from the code. G1 are the new general purpose workspace classes that we are introducing.

Related Issue(s)

Fixes ##10843

How to test

  • Go to the dashboard and select your preferred workspace class in the settings
  • Open a workspace
  • You can check that you have the correct workspace class either by checking the labels on the pod (gitpod.io/workspaceClass) or checking the GITPOD_WORKSPACE_CLASS environment variable in the workspace. The available classes are g1-standard and g1-large.
  • Stop the workspace, then change your workspace class selection. Start the workspace again and check that the workspace still has the previously selected workspace class (the workspace class on a workspace needs to stay the same as otherwise downgrading to a lower workspace class could mean that content init will fail due to storage size limit).
  • Start a new workspace. The workspace should have new workspace class that you have configured.
  • Turn off the feature flag, then start a workspace. The workspace class configuration in the settings menu should be gone and the workspace should have the "default" workspace class instead of one of the new workspace classes. There should be no entry in the workspaceClass column of the workspace and workspace instance.
  • Stop the workspace, then turn on the feature flag again. Now start the workspace you just stopped. This tests if a workspace that has been created before workspace classes still starts correctly. The workspace will get assigned a class based on if the user "has more resources". That means either g1-standard will be assigned or g1-large.

Release Notes

None

Werft options:

  • /werft with-preview

@Furisto
Copy link
Member Author

Furisto commented Jul 13, 2022

/werft run

👍 started the job as gitpod-build-fo-use-classes.11
(with .werft/ from main)

@Furisto
Copy link
Member Author

Furisto commented Jul 13, 2022

/werft run with-preview with-clean-slate-deployment

👍 started the job as gitpod-build-fo-use-classes.12
(with .werft/ from main)

@Furisto Furisto marked this pull request as ready for review July 13, 2022 12:56
@Furisto Furisto requested a review from a team July 13, 2022 12:56
@github-actions github-actions bot added the team: webapp Issue belongs to the WebApp team label Jul 13, 2022
@Furisto
Copy link
Member Author

Furisto commented Jul 15, 2022

@geropl PTAL

@@ -237,6 +237,22 @@ func configmap(ctx *common.RenderContext) ([]runtime.Object, error) {
// default limit for all cloneURLs
"*": 50,
},
WorkspaceClasses: []WorkspaceClass{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the config we want to deliver for Self-Hosted? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. @kylos101 @atduarte Are we ok with these workspace classes for self-hosted?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think we would want to have the two workspace classes as default for Self-Hosted. It's an advanced feature and the initial installation should be as simple as possible imho.

Would it be hard to have the default for self-hosted only be the standard?

cc @lucasvaltl as he is responsible for defining the self-hosted offering

Copy link
Member

@geropl geropl Jul 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea was to deliver what we currently do for SH: one "default" class. This config should then be exposed under experimental.webapp.workspaceClasses, and the concrete values set here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@geropl agreed, thanks for linking to the concrete config in ops, too

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah default for self-hosted for now should be a single workspace class - to keep installation simple. Right now even that class is not made obvious - but is rather just a default that sets a request but no limits.

We should however think about how to properly allow for configuration of this (and #10805 is likely a better place to discuss this). Fwiw, I don't think it makes sense to make this part of the installation config - this might be something a user wants to change over time, specifically a user that is not the "installer persona" but rather an "project configurer" / an admin. It is likely better to expose this in the admin UI or team settings page.

}

if (!workspaceClass) {
workspaceClass = this.config.workspaceClasses.find((cl) => cl.isDefault)?.id ?? "";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel this should be in a function inside a namesapce WorkspaceClasses so that we can test it etc.
@Furisto Let me find a couple of minutes and I can provide a commit to show what I mean.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Furisto Here is a commit showing what I mean: 7412eb0

I think it make sense to incorporate that commit + exposing of that config under "experimental" into this PR, and then we should be fine to merge. ✔️

☁️ Ideally we should also have tests for those functions.

@Furisto Furisto requested a review from a team July 19, 2022 11:48
@github-actions github-actions bot added the team: delivery Issue belongs to the self-hosted team label Jul 19, 2022
@Furisto
Copy link
Member Author

Furisto commented Jul 19, 2022

@geropl PTAL

@@ -210,6 +211,14 @@ type UsageConfig struct {
CreditsPerMinuteByWorkspaceClass map[string]float64 `json:"creditsPerMinuteByWorkspaceClass"`
}

type WebAppWorkspaceClass struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

Copy link
Member

@geropl geropl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM (as discussed), tested and work as expected. 🎉

Note that:

  • I could not test "g1-large" because preview envs now contain a single class only ✔️ (the UI still allows to select two classes, which we should clean up, by making it dynamic based on the config, in a follow up PR, before the SH release as discussed here /cc @lucasvaltl )
  • I did test default -> g1-standard after enabling the feature flag and the other scenarios ✔️
  • on workspace stop, I always got this error: container workspace completed; containers of a workspace pod are not supposed to do that. Reason: But I assume it's independent of this PR

Really looking forward to have this in prod! 🧡

Furisto and others added 2 commits July 20, 2022 18:08
- Use latest workspace instance to set workspace class
- Add more detailed configuration for workspace classes
- Make workspace classes configurable in installer
Copy link
Contributor

@Pothulapati Pothulapati left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I tried this on a self-hosted instance with default settings (using local-preview. This part of the build so not that hard to test. Just using the relevant build image should be enough)

  1. I get two instances on the preferences settings
    Screenshot 2022-07-21 at 10 33 32 AM

  2. But setting them/changing them does not seem to do anything and always give me a default workspace class

/ # kubectl describe pod -l workspaceType=regular | grep workspaceClass
              gitpod.io/workspaceClass=default
              gitpod.io/workspaceClass=default

So, We should not even be having the preferences option then right? seems like they seem to be set in the UI https://github.com/gitpod-io/gitpod/blob/main/components/dashboard/src/settings/selectClass.tsx#L50. Shouldn't it instead be based on a config?

This could be a separate PR. Approving this hence.

/hold just in case.

@Furisto
Copy link
Member Author

Furisto commented Jul 21, 2022

@Pothulapati That's right. There will be a separate PR for dynamically displaying the workspace classes.

@Furisto
Copy link
Member Author

Furisto commented Jul 21, 2022

/unhold

@roboquat roboquat merged commit 53e47b2 into main Jul 21, 2022
@roboquat roboquat deleted the fo/use-classes branch July 21, 2022 08:10
@roboquat roboquat added the deployed: webapp Meta team change is running in production label Jul 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production feature: workspace classes release-note-none size/XL team: delivery Issue belongs to the self-hosted team team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants