Can we use terraform variable withuse_managed_variable set in the coder terraform provider?

Can we use terraform variable with use_managed_variable set in the coder terraform provider?

For detecting pushed templates with legacy params? Yes, that's the assumption 👍

Can we use terraform variable with use_managed_variable set in the coder terraform provider?

For detecting pushed templates with legacy params? Yes, that's the assumption 👍

I mean after the deprecation. Can we still use them to store sensitive data?

I mean after the deprecation. Can we still use them to store sensitive data?

After deprecation, users will be able to use Terraform variables only asmanaged ones.

add a permanent banner highlighting that the workspace with legacy parameters is not supported

show warning in the CLI

try to find a way to delete the impaired workspace if it requires Terraform variables to do that

1. Template author should addfeature_use_managed_variables = true to the template.
2. Update the affected workspace.
3. Delete the workspace.

Clean!

Awesome!! How will the template author know to do steps 1-3? Are there cases where deleting the workspace will not work until steps 1-3 are completed?

Perhaps we should link to some docs on how to clean up the old workspaces in the message.

try to find a way to delete the impaired workspace if it requires Terraform variables to do that

1. Template author should addfeature_use_managed_variables = true to the template.
2. Update the affected workspace.
3. Delete the workspace.

Clean!

1. I have a workspace up that uses legacy parameters
2. Upgrade Coderd
3. Stop the workspace

I get failed stop

Error: No value for required variableon main.tf line 27:  27: variable "legacy" {The root module input variable "legacy" is not set, and has no default value. Use a -var or -var-file command line argument to provide a value for this variable.

But, then, if I

4. Update the template to convert to a rich parameter, setfeature_use_managed_variables = true
5. Update the workspace (it prompts me for the parameter value --- no migration of my old value)

It succeeds building.

A little gnarly, but works out ok in the end.@bpmct you ok with that?

So this UX is confusing:

If I try to change to an old version with legacy parameters, it

a) doesn't change the version
b) tells me to delete the workspace

The warning box that comes up should say something like, "Unable to change version. Legacy parameters in use on this version aren't supported any more."

The error message says, "Legacy parameters are not supported anymore, delete the workspace and the related template."

This isn't great advice

If you do delete the workspace, the delete job will always fail because there are variables in the template that we aren't supplying value to. It then tells you to have an admin delete with--orphan, but we could skip straight to this, instead of having the user bang their head against a failed delete.

Also, deleting the template is not necessary. The template author can just rework the variables to "coder_parameters", push a new version, and then people can upgrade.

Basically, there is nothing a regular (non-template-admin, non-owner) user can meaningfully do if they have a workspace that uses legacy parameters after upgrade. Our advice to end users should just be, "Contact your administrator for assistance."

Our advice to admins (this can be in docs & release notes, it doesn't have to be in the dashboard IMO) should be:

Decide whether you are going to fix the template to use rich parameters. If you aren't going to fix it, then delete all workspaces with--orphan, manually clean up infrastructure resources, and delete the template. If you are going to fix it, then push a new version, and upgrade all the affected workspaces.

The warning box that comes up should say something like, "Unable to change version. Legacy parameters in use on this version aren't supported any more."

It is one more API to cover with extra condition, should not be hard to do this.

Despite that, I think that we should not invest much time and efforts on making the whole operation really smooth. In theory, this is already beyond the deprecation timeline (end of April), so most of the users should be already migrated. I doubt that these paths will be actively followed.

Basically, there is nothing a regular (non-template-admin, non-owner) user can meaningfully do if they have a workspace that uses legacy parameters after upgrade

Thanks for providing UX feedback. "Contact your administrator for assistance." seems to be a better fit and actionable for every regular user. I also like the idea to describe admin steps in docs. Happy to adjust both.

It is one more API to cover with extra condition, should not be hard to do this.

Actually it is more challenging that I expected, as "Change Version" dialog uses the same API method as Start or Stop workspace(/builds). If it isn't required, I wouldn't like to add more UI logic to handle this case, as this is contrary to what we're trying to achieve - remove references to legacy stuff.

I decided to just adjust wording here. Let me know your thoughts:

EDIT:

Maybe it is better to keep docs aside from this PR as it is huge and hard to review. I will push the docs update in the follow-up as I wouldn't like to keep this submission open for a long time.