Open dnozay opened 2 years ago
Thanks for reporting this, @dnozay.
For most commands -state=...
is a legacy option for the local backend only, but it seems like it intentionally has a different meaning for terraform workspace new
, because that command is handling the option inline itself rather than passing it over to the backend as other commands do:
(statePath
in the above is what the -state=...
option gets decoded into.)
The logic here seems to be backend-agnostics:
With that said then, it's not clear to me why this behavior would be different depending on which backend you've selected and I wonder if something else was confounding things here that made it seem like the GCS backend behaved differently. I'm going to reclassify this as a general CLI bug for the moment to recognize that, since I think we ought to try to prove it as being an S3-backend-specific issue before we pass it over to the AWS provider team (who maintains that backend).
As mentioned in the repro scenario
terraform workspace new -state=tf.state.default ${USER}_testing
terraform state list | wc -l
shows no resources when using s3 remote state; I've also tried with gcs, and that worked much better.
This is still an issue on:
Terraform v1.3.1
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v4.32.0
I have the same problem with:
Terraform v1.4.0
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v4.57.1
When state is stored in Azure storage account it works.
Terraform Version
Terraform Configuration Files
Debug Output
Expected Behavior
Creating a new workspace should work and use input state as base.
Actual Behavior
Steps to Reproduce
Additional Context
without
TF_LOG=trace
As you can see in the steps, workaround is to explicitly push the state
However, this is using the same
lineage
which could be a problem. In that regard, S3 backend and GCS backend are not working the same.