Resource does not have attribute 'id' for variable #6991
Comments
|
And the |
|
I think we are having the same issue. Except its in 0.7.2 so it seems unresolved still. |
|
Confirming this is still an issue in 0.7.4 as well. |
|
And still in 0.7.7. |
|
Thanks for that debug output, @carlossg. Here's what I think is the most relevant subset of it: |
|
Since Terraform doesn't always include the resource id in the log output it's kinda hard to be sure which log lines belong to the processing of which security group here, but I noticed a few things that seem like plausible leads:
So with all of this said, eventual consistency issues on the AWS end do seem to be a likely cause here; in an earlier step we verified that the security group had indeed been created, but perhaps it takes a while before the API will consistently report its creation. Assuming all of this is the correct explanation (which I wasn't able to verify, due to not being able to repro |
|
Over in #9719 I made some changes to make Terraform fail in a different way when this situation arises: rather than quietly dropping the resource from the state, it will instead halt with an error and write the partial resource to the state, at least allowing the operation to be retried in a subsequent run of Terraform. I also added some logging for the case where we find during Neither of these things are going to actually address the problem described here, but they will hopefully confirm the theory that the EC2 API is giving us inconsistent results and we can then figure out the right way to be more resilient to that inconsistency. |
|
Just want to add another data point here. I was mysteriously getting the following error consistently (i.e. not an AWS eventual consistency issue): I finally discovered that the real issue was that But because the execution kept running, the error message I saw wasn't helpful. |
…stency issues It appears, based on the report in hashicorp#6991, that the EC2 API is being inconsistent in reporting that a security group exists shortly after it has been created; we've seen Terraform get past the "Waiting for Security Group to exist" step but then apparently detect that it's gone again once we get into the Update function.
…stency issues It appears, based on the report in hashicorp#6991, that the EC2 API is being inconsistent in reporting that a security group exists shortly after it has been created; we've seen Terraform get past the "Waiting for Security Group to exist" step but then apparently detect that it's gone again once we get into the Update function.
|
I just saw this as well. One of my route tables wasn't created, so the dependent resources error-ed out. Running |
Make security groups more resilient to eventual consistency errors by adding retries on the existence function in read and update. See: hashicorp/terraform#6991
|
I've got similar error for despite my resource got And somebody got similar issue at: https://docs.cloudposse.com/troubleshooting/error-applying-terraform-plan/ |
|
I got the same issue with an aws_rds_instance. The problem was that I passed in an AWS KMS alias and not a valid ARN. It seems like the provider validates and the error is not catched correctly or something similar. Found out about the Alias vs ARN issue by running |
|
Hi all, We had a few different root causes leading to errors like this in Terraform 0.11 and earlier. Eventual consistency was one such problem, but the general concern was that in earlier versions Terraform would not perform thorough checks on the consistency of what is returned by a provider, and thus a provider behaving oddly would usually lead to a confusing downstream error with insufficient context. Terraform 0.12 includes some fixes for known issues in this area, and it also includes improved safety checks so that provider inconsistencies can be caught earlier and reported with more context. The specific codepath that generated the errors discussed in this issue doesn't exist anymore in Terraform 0.12, so we're going to close this one out under the assumption that all of the reports here were caused by issues that we found and fixed in the Terraform 0.12 cycle. If you are using Terraform 0.12 and are still running into weird errors that feel similar to those here (although the exact text will be different, due to the rewrite of this portion), please do open a new issue for it so we can capture some updated reproduction information against the new codepaths. Thanks for reporting this! |
|
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. |
ghost
locked and limited conversation to collaborators
We are getting this error from time to time, seems a race condition when AWS is slower than usual
the terraform.tfstate file seems corrupt, with no info about the security group created
Terraform Version
0.6.15
Affected Resource(s)
Terraform Configuration Files
References
The text was updated successfully, but these errors were encountered: