add command for force-unlock

[alec-rabold]

Adds command for terraform force-unlock -force LOCK_ID [DIR]. Assumes the -force option as it's practically required in this context.

Regarding forceUnlockDirArgMaxVersion, the command docs appear to indicate that the [DIR] positional argument is still valid but it was effectively removed around v0.15.0 in this commit. Just wanted to clarify where that was coming from since it was failing v0.15.x+ test cases.

(Related to #222)

[radeksimko]

FWIW We have an open PR #100 which discusses the [DIR] positional argument, but have not yet decided whether/how to proceed with that PR.

Aside from that - do you mind sharing some details about your use case here?

My understanding is that when state remains locked and Terraform returns that error, it is for that exact reason that "something unexpected happened" and essentially manual intervention is recommended. i.e. I would not expect anyone to build any sort of automation script that automatically unlocks the the state.

[alec-rabold]

Thanks for the context on chdir/[DIR], I think it makes sense to let that PR you mentioned guide the discussion there 👍

As for use cases, I agree that automatically unlocking the state comes with its fair share of risk and uncertainty.

Currently we're running Terraform in a Kubernetes ecosystem to support self-service manifests (sort of similar to aws-controllers-k8s). Every so often we're hit with edge-cases that lock a resource's state like OOM kills or other non-graceful terminations. Since the TF project files aren't meant to be accessed locally, we manually signal that a resource should force-unlock by using an annotation on the k8s object (we're running a home-grown force-unlock implementation).

All that being said though, I do think there's valid use-cases where a higher-order construct can decide whether or not to force-unlock automatically (e.g. leader-election in our case, possibly).

[kmoe]

I'm happy with this. The handling of [DIR] is consistent with other commands, and, as you note, the Terraform docs, although its use will produce an error in v0.15+. We could add a tf.compatible for it here, or we could wait for it to be caught in #121. I don't think it matters too much.

Await re-review by @radeksimko before merge.

[radeksimko]

Yep, I'm happy with this as well 👍🏻 Thanks for sharing the context.