Add support for locking a workspace

[dkirrane]

Add support to the tfe_workspace resource to allow locking the workspace. Currently, it looks like this is only possible via the Terraform Cloud UI.

[chrisarcand]

May I ask for a little more detail in to your use case? How would you use this in your regular workflow?

This one's interesting because...

• Although it might still be useful for other workspaces, there's an edge case where this would not be possible to apply with the remote backend for Terraform Cloud/Enterprise - an open lock is required for remote operations, so attempting to apply this to the workspace you're applying with would not work, I believe.
• I can't visualize at the moment how one would design the API to include force unlocking, if that's a thing that's also desired.

[jgrumboe]

At my company we have one "bootstrap" workspace, which manages the rest of our others (~70). A locking feature could be useful and it wouldn't interfere with the running "bootstrap" workspace. Does the mentioned admin access correspond to an org token? If yes, also force unlocking would work because we need an org token to create workspaces.

[arbourd]

We also use a single workspace to manage another 33. Would love to be able to bitflip locking from Git instead of the GUI. 😁

[Sreerag74031]

we also use workspace to manage other workspaces. our use case is ability to create a workspace, lock the workspace so we can migrate the state file from other backend using create state version feature #357 , unlock the workspace all in one tf run.

So we would like workspace lock/unlock feature in seperate resource/data and not included in workspace resource.

[jgrumboe]

My 2 cents here https://github.com/hashicorp/terraform-provider-tfe/issues/357#issuecomment-912671531 apply to this issue here also.

[Satak]

We are migrating multiple organization to single organization and I would like to lock target organization workspaces before we have migrated states. Really surprised that there is not lock option available in the terraform workspace resource :-O

[fatbasstard]

Any update on this one? Could really use this functionality

[nfagerlund]

1. We're interested in meeting users' needs around handling workspace locks correctly when they relate to provisioning tasks.
2. We're very wary about the prospect of managing the workspace lock as a resource.

The problem here is that locks are part of a workspace's post-provisioning operational lifecycle, so the idea of a lock resource that we maintain and ensure the existence of on every run seems wrong — like managing a running process on a machine instance resource. That's not the level of interaction that Terraform should be operating on! Also, handling unlocks of a workspace via a resource lifecycle sounds quite nasty.

(This is the same objection we'd have to managing a state version or configuration version as a resource — they're part of the post-provisioning operational lifecycle, and outside Terraform's proper domain of concern.)

But! What it sounds like from the comments so far is that there's sometimes a need to orchestrate a workspace's lock state as part of the process of getting the workspace fully provisioned, most notably when migrating state from another system or another TFC/TFE organization.

Instead of building a primitive for managing arbitrary locks, I'd rather solve the specific provisioning use cases, since I think that would result in fewer footguns. In other words, do something more like passing a cloud-init config to a machine instance, rather than trying to act as an intermittently-running process monitor on the instance.

It sounds to me like there might be two of those provisioning use cases:

• Migrating a workspace: the workspace should start its life with some specific existing state content. The lock is actually incidental in this case, it's just that it's currently necessary for doing the state upload; presumably migrating users would be fine with just passing the state and letting the provider sort out the details.
• Holding the door for arbitrary further setup: the workspace should start its life in a locked state to block runs while an admin sorts out something, but the lock shouldn't be considered an integral part of its ongoing existence, and Terraform shouldn't try to re-lock it on subsequent runs. This would basically be an escape hatch for doing manual or procedurally automated work that the provider can't represent in a meaningful or reliable way.

Are there other use cases I'm missing? Anything weird that people need to have happen during resource destruction?

[barrettclark]

I'm closing this in favor of https://github.com/hashicorp/terraform-provider-tfe/issues/361, which is the only domain-appropriate use case we're currently aware of for locking within the provider.