Note

We invite your participation on this feature proposal. Please keep comments substantive. We'd especially love feedback on ways in which this feature may be useful to you and/or where you feel this RFC falls short.

Problem Statement

Workspace templates may be defined with a range of configurable parameters - such as CPU, RAM, disk size, operating system, cloud region, etc. Users may not always know which settings are most appropriate for their needs, and default values don’t necessarily fit every scenario. New or non-technical users may find it especially difficult to choose the right settings.

Furthermore, giving users complete freedom to select these parameters can lead to a proliferation of different workspace types and sizes, making it harder to manage them effectively.

UX & Design

One or more coder_workspace_preset blocks can be added to a template, which allows operators to choose combinations of coder_parameter values which together form a “preset”.

Any parameters which are not part of the preset will still be displayed.

A “Custom” option will also be (configurably) available for users to choose their own values.

User Stories

• As a template admin, I want to define combinations of parameter values, in order to give my users a simplified approach when creating workspaces
• As an operator, I want my workloads to conform to certain predefined shapes & sizes, so I can cost-efficiently run (easier to bin-pack) compute
• As a non-technical end-user, I don’t want to have to choose how much CPU/RAM/disk my workspace should have - I just want a workspace with the standard set of options for my department
• As a technical end-user, I want options to choose preset sizes of workspaces (S/M/L) depending on my use-case, as a convenience
• As a technical end-user, I want a “Custom” option where I can still modify individual parameters where no preset matches my particular use-case
• As an operator, I want to disable the “Custom” option if I’m satisfied that the presets represent the full suite of requirements for my users, in order to control cost and tame infra complexity

Requirements

Initial Functional Requirements

• MUST introduce new Terraform datasource (coder_workspace_preset) in provider
• MUST be built in order to accommodate integration with Prebuilds (TODO: link to RFC)
  • we will likely introduce a prebuilds attribute on the coder_workspace_preset block, specifying how many workspaces using the preset’s parameter values must be prebuilt
• MUST work for the web UI and the CLI alike
• MAY validate on the frontend before submission
• MAY validate on template import
• MAY change preset after-the-fact when updating a workspace

Initial Non-functional Requirements

• MUST be clear and easy for non-technical users to create workspaces from presets, as this cohort is likely to benefit the most

Eventual Requirements

• MAY perform frontend validation of selected preset parameter values on submit
• MUST produce template insights about usage of presets

Implementation

Creation Flow

1. template admin adds one or more coder_workspace_preset blocks to their template
2. template is imported and a new version is created
3. the coder_workspace_preset blocks’ properties will be accessible in the planResources func, and will be persisted to the database
4. user goes to create new workspace via web UI or CLI
5. presets are fetched and listed
6. preset is chosen
7. validation occurs
8. workspace build initiated using given parameters, if valid
9. selected preset is tracked for later insights

Update Flow

1. user goes to modify workspace
2. previously selected preset should be set
   1. if parameters have been changed from the preset, this must be indicated
   2. the preset used to create the workspace must be indicated
   3. a new preset can be selected, provided none of the parameters are immutable
3. parameters are submitting to workspace build API
4. workspace is updated with given parameters