Terraspace force_unlock - How it works?

Terraspace
1

Hi @tung,

I would like to know how force_unlock works?
I got an error when I tried to unlock my tfstate using terraspace force_unlock stack_name id

...............
Created .terraspace-cache/dev/westeurope/stacks/cdp_vmss_linux/outputs.tf
Created .terraspace-cache/dev/westeurope/stacks/cdp_vmss_linux/variables.tf
Layers for cdp_vmss_linux:
    app/stacks/cdp_vmss_linux/tfvars/base.tfvars
Created .terraspace-cache/dev/westeurope/stacks/cdp_vmss_linux/1-base.auto.tfvars
Built in .terraspace-cache/dev/westeurope/stacks/cdp_vmss_linux
Current directory: .terraspace-cache/dev/westeurope/stacks/cdp_vmss_linux
=> terraform force-unlock -force 009e3fcf-374f-9e8c-5602-a96b2facb6b8
╷
Waiting 2s before retrying
Terraform reinitialization required detected. Will run `terraform init` and try again.
Retry attempt: 2
Terraspace::InitRequiredError
=> terraform init -get -input=false >> /tmp/terraspace/log/init/cdp_vmss_linux.log
╷
│ Error: Either an Access Key / SAS Token or the Resource Group for the Storage Account must be specified - or Azure AD Authentication must be enabled
│ 
│
╵

=> terraform force-unlock -force 009e3fcf-374f-9e8c-5602-a96b2facb6b8
╷
ERROR after max retries 1: ╷
│ Error: Backend initialization required, please run "terraform init"
│
│ Reason: Initial configuration of the requested backend "azurerm"
...................

At the end I unlocked my tfstate by going to my stack folder in .terraspace-cache folder to run terraform command force-unlock manually with the giving id (which was wrong then the terraform command gave me the right id)
I don’t remember if I made something wrong however my question:
Why the log shows a different layering when performing force_unlock?

This is my current backend key config:
key = “<%= expansion(’:APP/:ENV/:LOCATION/:BUILD_DIR/terraform.tfstate’) %>”
(so in cache =.terraspace-cache/cdp/dev/westeurope/stacks/cdp_vmss_linux/terraform.tfstate)
but why does the force_unlock command generate a different “backend key” then ?
(so in cache = .terraspace-cache/dev/westeurope/stacks/cdp_vmss_linux/)
or may I guess it’s an issue when we have a custom “backend key”?

That’s the reason I got the error ?

I hope my question is clear as I am trying to understand the reason of my error.
Thanks

btw: it seems that force_unlock and force-unlock commands can be used. I guess it’s better to use force-unlock as it’s the same command name as terraform

2

Unsure :thinking:

terraspace force_unlock stack_name

Builds the project and cd’s into it and runs terraform

terraform force-unlock -force 009e3fcf-374f-9e8c-5602-a96b2facb6b8

You mentioned that the backend key is custom. That might have to do with it. If it’s being generated dynamically based on some logic and that logic relies on let’s say an TS_APP variable being set. IE:

.terraspace-cache/cdp/dev/westeurope/stacks/cdp_vmss_linux/terraform.tfstate

vs

.terraspace-cache/dev/westeurope/stacks/cdp_vmss_linux/terraform.tfstate

You probably have to run the terraspace command with the same TS_APP to make sure it uses the same statefile. Just a guess, maybe:

TS_APP=cdp terraspace force_unlock stack_name
3

Hi @tung
Thanks a lot. yes… I was tired, lol… i didn’t input the env var for the force_unlock command.

In fact I combine terraspace with a makefile which providing all the env variable on the fly but I didn’t implement the force_unlock “makefile target” to run the terraspace force_unlock with the env vars.

Instead, I just run “terraspace force_unlock stack_name” without any env vars. I guess that’s the reason he created the “default” “key” structure in the cache folder.

Thanks again, my bad… all good :wink: