-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provider produced inconsistent result after apply - aws_vpc_endpoint_route_table_association.s3_vpc_endpoint #12449
Comments
@ffran09 If you add |
Yes, we still get the same error with the count variable. |
I just run into this error message, too.
|
Relevant: This is most likely an eventual consistency issue. The association is successfully created but when the provider then turns around and reads back the state, the AWS EC2 service can't find it. |
I also see it with aws_network_interface_sg_attachment
|
I just suffered this; it seemed to have setup the route associations. I re-ran the apply and it needed to add the network associations which worked (even though they are already there). Then another plan showed all was good. So I guess the answer is just do another apply? |
Well, yes and no. |
Seeing this problem with Terraform v0.12.27 and AWS provider v2.70.0 This issue seems to be non-deterministic. |
Same issue. Re-applying the plan does resolve it.
|
Same issue. Encountered with TF v0.12.28, and provider v3.11.0. |
Seeing this for TF v0.12.29 and provider 2.70.0. Generally seems to be the s3 or dynamoDB endpoints. Non-deterministic, probably happens 1 time in 20. |
Same issue with TF 0.13.5 and provider v3.12.0.
|
We are on Terraform 0.13.3 and on hashicorp/aws v2.70.0. Apply failed with
The next apply failed with
So did the one after it. We had to manually detach the Security Group, then apply again. That resolved it. |
This comment has been minimized.
This comment has been minimized.
Given that this is happening for |
Got it (though rarely, but causing serious issue when it happened) with |
I was able to reproduce this issue with terraform vpc module and dynamodb gateway enabled: module.vpc.aws_vpc_endpoint_route_table_association.private_dynamodb[0]: Creating...
Error: Provider produced inconsistent result after apply
When applying changes to
module.vpc.aws_vpc_endpoint_route_table_association.private_dynamodb[0],
provider "registry.terraform.io/hashicorp/aws" produced an unexpected new
value: Root resource was present, but now absent.
This is a bug in the provider, which should be reported in the provider's own
issue tracker. My terraform configuration looks like this: data "aws_region" "current" {}
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "2.70.0"
name = var.resource["name"]
cidr = lookup(var.cidr, data.aws_region.current.name, "")
azs = keys(lookup(var.azs, data.aws_region.current.name, {}))
private_subnets = [
for i in values(lookup(var.azs, data.aws_region.current.name, {})):
cidrsubnet(lookup(var.cidr, data.aws_region.current.name, ""), var.resource["subcidr_newbits"], var.resource["subcidr_netnum_private"] + i)
]
#public_subnets = [
# for i in values(lookup(var.azs, data.aws_region.current.name, {})):
# cidrsubnet(lookup(var.cidr, data.aws_region.current.name, ""), var.resource["subcidr_newbits"], var.resource["subcidr_netnum_public"] + i)
#]
manage_default_security_group = true
default_security_group_ingress = [{}]
default_security_group_egress = [{}]
enable_dns_hostnames = true
enable_dns_support = true
enable_s3_endpoint = false
enable_dynamodb_endpoint = true
}
variable "resource" {
type = map(string)
default = {
name = "devops"
subcidr_newbits = 3
subcidr_netnum_private = 0
subcidr_netnum_public = 10
}
}
variable "cidr" {
type = map(string)
default = {
"us-east-1" = "10.8.64.0/21",
"us-east-2" = "10.10.64.0/21"
}
}
variable "azs" {
type = map(map(string))
default = {
"us-east-1" = {
"us-east-1a" = 0
"us-east-1b" = 1
"us-east-1d" = 2
},
"us-east-2" = {
"us-east-2b" = 0
"us-east-2c" = 1
"us-east-2d" = 2
}
}
} For reference: |
Proposal to consistently deal with read-after-create failing: |
…create eventual consistency Reference: #12449 Reference: #16796 Output from acceptance testing in AWS Commercial: ``` --- PASS: TestAccAWSVpcEndpointRouteTableAssociation_basic (36.76s) ``` Output from acceptance testing in AWS GovCloud (US): ``` --- PASS: TestAccAWSVpcEndpointRouteTableAssociation_basic (40.65s) ```
…create eventual consistency (#18465) Reference: #12449 Reference: #16796 Output from acceptance testing in AWS Commercial: ``` --- PASS: TestAccAWSVpcEndpointRouteTableAssociation_basic (36.76s) ``` Output from acceptance testing in AWS GovCloud (US): ``` --- PASS: TestAccAWSVpcEndpointRouteTableAssociation_basic (40.65s) ```
I was wondering if anyone was able to work around this issue by adding a null resource with a small 5-30 second sleep on it. did anyone attempt to and/or succeed to resolve it in this manner? |
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
Community Note
Terraform Version 0.12.23 aws provider version 2.51.0
Affected Resource(s)
aws_vpc_endpoint_route_table_association.s3_vpc_endpoint
Terraform Configuration Files
Debug Output
Error: Provider produced inconsistent result after apply vpc.aws_vpc_endpoint_route_table_association.s3_vpc_endpoint[0], provider "registry.terraform.io/-/aws" produced an unexpected new value for was present, but now absent. This is a bug in the provider, which should be reported in the provider's own issue tracker..
Expected Behavior
Terraform apply should have been successful
Actual Behavior
Terraform apply fails
Steps to Reproduce
This does not happen all the time, running apply multiple times
The text was updated successfully, but these errors were encountered: