edits by @bpmct:

Problem statement

In Coder Classic, some parameters for workspaces are editable after the workspace is created, providing a helpful utility to users. Examples of these parameters are:

• image
• cpu allocation
• memory allocation
• disk size

Some parameters have specific rules when editing:

• disk size can only be increased, not decreased

Others cannot be edited, as Coder does support migrations and it would result in data loss:

• workspace provider
• CVM (true/false)

In Coder OSS, there is currently:

• no way to edit parameters for an existing workspace via the web dashboard
• no prompt in the dashboard when new variables are added to a template version and they "update" their workspace Pressing "Update" on a workspace does not prompt for newly-created variables #2660
• a way to dangerously edit ALL parameters for an existing workspace with coder update --always-prompt <workspace-name>
  • If I change the "region" of an existing workspace, it will delete the disk in one region and recreate it in another. The user looses the files in their home directory.
• no way to see what your existing parameters are. users need to re-select them from scratch.

Definition of done

Coder has documented (or implemented) best practices for disabling/handling "dangerous" parameters.

• Admins would likely have to indicate which variables are destructive, as every template differs

Users can safely edit their workspace's parameters from the web dashboard and CLI.

• Users can also see what their current parameters are in their workspace

Users are prompted in the web dashboard and CLI when they "update" their workspace and new variables are added to a template version

• Pressing "Update" on a workspace does not prompt for newly-created variables #2660
• This currently happens in the CLI, but not the web dashboard

Current workarounds

• Terraform's prevent_destroy and ignore_changes meta-arguments can be added to templates to ensure that changes to "destructive" parameters will not destroy critical resources, such as a home volume or persistent VM. However, this UX is not well-handled into Coder and will lead to confusing behaviors:

  User changes the region after a workspace is created, ignore_changes does not change the resources, user is confused why their change did not work and reports it to their Coder admin. While this prevented the workspace from deleting, the action didn't lead to the desired result.

  User changes the region after a workspace is created, prevent_destroy ensures the volume is not deleted, but the rebuild has failed. When viewing the logs, the user sees that the volume cannot be destroyed but doesn't understand that their change led to a failed workspace

  • prevent_destroy would also prevent the workspace from being deleted, since it cannot be referenced conditionally ("Variables may not be used here" for prevent_destroy hashicorp/terraform#22544). Thanks @kylecarbs

• User can dangerously edit their workspace with coder update --always-prompt <workspace-name> and has to remember / write down their previous values if they want to carry them over.

Archive