Allow specification of workspace class in project settings

[Furisto]

Is your feature request related to a problem? Please describe

Improve usability of #8261.

Describe the behaviour you'd like

As a user of Gitpod, I would like to specify the workspace class that should be used for the repository in gitpod.yml.

The file would like the following:

workspaceRequirements:
  class: g1-standard

or:

workspaceRequirements:
  class: 
    - g1-standard
    - g2-foo-bar

It should behave as such:

1. The first workspace class available is used (in prebuilds and regular workspaces).
2. If no workspace class is set in the .gitpod.yml or those are not available:
   a. On Prebuilds, use the default (g1-standard)
   b. On regular workspaces, use the user preference.

Describe alternatives you've considered

Specify workspace class on a per project basis.

Additional context

Affected components:

• gitpod-protocol
• server

Why allow the specification of a list of workspace classes? Workspace classes names and definitions differ between gitpod installations, but the .gitpod.yml is the same for all. As such, we must allow users to define multiple a choose the first one available.

Required actions:

• Update documentation
• Talk with @gtsiolis to update the workspace class preferences to include the id, and implement it

Question: Can we have different types (array and string) being processed in the workspaceRequirements.class field? From @WVerlaek: Possible in Go, with a slight workaround: go-yaml/yaml#100

[svenefftinge]

I think we should only specify system requirements in .gitpod.yml, that the system then tries to satisfy.
Depending on that configuration a Gitpod installation could propose/select a matching workspace class. Workspace classes will vary per installation, per user as well as over time, so I'd rather not reference them from .gitpod.yml.

FWIW .devcontainer does it like that as well [1].

[atduarte]

Would the configured values in the .gitpod.yml always take precedence over the user settings? 🤔

Only use case I can think of in which that doesn't fit is whenever you have a project to which you may want to use a different workspace class depending on the type of work you are going to do. For example, you might be opening the project to edit some docs to train a model which require more resources and a GPU, respectively. This is a somewhat similar problem to the fact that long prebuild/command tasks need to run independently of what you are planning to do on the repository, and could be tackled later.

[jldec]

@atduarte I suggest renaming this issue to "Auto-select workspace class based on system requirements in gitpod.yml" to match the comment.

Allowing users to configure their preferred workspace class is a reasonable first step toward automatic workspace class selection, but it also introduces friction e.g. for onboarding large teams where everyone is using non-default workspace classes, or for users who would like to open different workspaces classes for different project repos.

cc: @svenefftinge

[atduarte]

@jldec I'm still unsure about whether we should auto-select based on system requirements or require users' to specify the class name. The former limits the selection to a few characteristics that may not represent the full set. For example, if there are two workspace classes with the same number of cores but different frequencies it would lead to problems. On the other hand, the .gitpod.yml would be more readable.

Given that both are not incompatible, what if we started with the simplest option (i.e. requiring user to specific the workspace class name) that covers all possible scenarios and later consider introducing the alternative of specifying the workspace class via system requirements?

[jldec]

Starting simple is 😎.
How about allowing a list of preferred workspace classes (for portability / cross-compatibility).

[atduarte]

💭 Would ensuring that whenever a workspace class is deprecated a "replacement" is defined address your concerns? E.g. when deprecating g1-standard, the admin sets g2-foo-bar as its replacement, so that a .gitpod.yml with g1-standard will now start g2-foo-bar. Whenever no replacement is set, and the class is not available, warning would be showed and user preference used instead.

[jldec]

I was thinking of a scenario where a repo is used in both self-hosted and gitpod.io.
In that case specifying both preferred classes would work.

(the inspiration for allowing a list of multiple classes came from the way fonts work in CSS - you can specify preferred fonts in a list to support system fonts with different names across OSes)

[atduarte]

Makes sense 👌 My concern was that we would make it less readable/intuitive for the majority to address a corner case, but instead of an array we can use a comma-separated string like class: g1-standard, foo-bar.