Terraform: "missing state name" error when upgrading from 0.8.7 to 0.9.3

[drewandersen]

Trying to upgrade from Terraform 0.8.7 to 0.9.3.

Executing the commands terraform remote and terraform plan in version 0.8.7 seem to work correctly.

Executing terraform init in 0.9.3 yields the following message:

Initializing the backend...
New backend configuration detected with legacy remote state!

Terraform has detected that you're attempting to configure a new backend.
At the same time, legacy remote state configuration was found. Terraform will
first configure the new backend, and then ask if you'd like to migrate
your remote state to the new backend.

Do you want to copy the legacy remote state from "s3"?
  Terraform can copy the existing state in your legacy remote state
  backend to your newly configured backend. Please answer "yes" or "no".

  Enter a value: 

When 'yes' is entered, the local terraform.tfstate file is refreshed based on the terraform.tfstate stored in the remote backend. If 'no' is entered, the local terraform.tfstate file only includes data about the backend.

Either way, the following error message occurs when executing terraform plan in version 0.9.3:

Error refreshing state: 1 error(s) occurred:

* terraform_remote_state.us-west-1: terraform_remote_state.us-west-1: error loading the remote state: missing state name

[okushchenko]

I have the same issue with version 0.9.4. After the upgrade of a huge number of tfstates to the new version (0.8.7 => 0.9.3) this issue manifested in only a few of them.

[apparentlymart]

Hi @drewandersen and @okushchenko! Sorry this didn't work out as expected.

Based on this error message it sounds like Terraform's record of the current state environment has got corrupted. Specifically, Terraform seems to think that the current environment name is the empty string.

Do either of you have a file .terraform/environment present after completing this migration (answering "yes")? If so, what are the contents of it?

The expected behavior is that there would initially be no such file, which would cause Terraform to use the default environment name, which is literally default.

It might also help to see the output of the command terraform env list, which will let me see if the record of the environments _themselves_ is intact. If things are working as expected, right after migration the output should look like this:

$ terraform env list
* default

[drewandersen]

Hello, @apparentlymart,

Thank you for your response!

I don't see a .terrafrom/environment file in the working directory following the migration, and the output from terraform env list is simply * default.

I executed terraform plan with TF_LOG="TRACE" env activated. The last line before the error was: 2017/05/04 10:41:03 [DEBUG] dag/walk: upstream errored, not walking "root". Also, if it helps, my Go runtime is 1.8.

Anything else I can provide that would be helpful?

[okushchenko]

I've fixed it for myself by deleting the remote state from the terraform state using terraform state rm terraform_remote_state.STATE_NAME and then refreshing the state with terraform refresh

[apparentlymart]

Oh I totally missed on the first pass that this was the terraform_remote_state data source... in which case my previous theory is invalid because that's an entirely different trigger point in Terraform that doesn't consider the current environment.

It seems like something weird is going on related to 6c3800d17f246a9e125356fd1d0a81f9da3058da where we added support for retrieving non-default environments from this data source. Based on @okushchenko's comment it sounds like the default value of that argument (literally "default") is not applying for some reason.

The other thing I notice is that both of you are using terraform_remote_state as a resource block, which is a deprecated way to use it. I think if you switch to the currently-recommended form using a data block then this problem will go away. This issue seems to be related to the previously-unset value of environment being interpreted as an empty environment string in newer versions, but data blocks don't have that problem because they don't retain any state from one run to the next:

data "terraform_remote_state" "us-west-1" {
  # ... same config as before ...
}

It seems like there is an odd bug here to fix, but since we're planning to drop support for the deprecated form in the next non-patch release I expect we will not actually fix this and will instead just recommend switching to this new form now, ahead of its removal.

[okushchenko]

@apparentlymart thanks for the detailed explanation.

[drewandersen]

I was previously using the remote state in v0.8.7, but am now defining the backend as:

terraform {
  backend "s3" {
    bucket = "mybucket"
    key    = "path/to/my/key"
    region = "us-east-1"
  }
}

...per this page: https://www.terraform.io/docs/backends/types/s3.html

Still getting the same error message. @okushchenko's fix didn't work for my setup, either.

[apparentlymart]

@drewandersen the problem here is with a resource "terraform_remote_state" "us-west-1" block in your config, rather than with the backend configuration. That is, it's the fetching of your upstream state that is failing, rather than the state for your current configuration.

[drewandersen]

@apparentlymart Thanks again for your help. I'm still confused. If I change the current config to use a data "terraform_remote_state" block or if I remove the "terraform_remote_state" block altogether I receive the same error message. So I'm still not sure how to get the error message to stop occurring.

[apparentlymart]

Oh, I suppose Terraform is still trying to refresh that old resource because it hasn't been "destroyed" yet. (Destroying a terraform_remote_state is actually a no-op, but Terraform's lifecycle expects to need to do it for managed resources.)

I think you should be able to bypass the error by changing it to be a data block (which, by the way, also requires changing references to its attributes to use the data. prefix) and then running the terraform plan with -refresh=false to skip the automatic refresh for that single run. Then Terraform should see that it needs to destroy the remote state resource, and after you apply that plan the error should go away.

Alternatively if you'd rather not do a plan/apply cycle then after changing resource to data you can directly remove the old resource from state, causing Terraform to "forget about it":

terraform state rm terraform_remote_state.us-west-1

On the next run Terraform should no longer do anything with the former resource.

[drewandersen]

Thanks, @apparentlymart, that did the trick!

[gposton]

I had an old state file in s3 with the same name. It was left around from a change we made awhile back. I just deleted it and things started working again.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.