We are experiencing some issues at the time we deploy our API Gateway into AWS. It seems to be an error recently introduced since we had never seen it before and we haven't really modified our code base.
At the time we are deploying the API for the first time every resource seems to applied correctly. However, at the second and so on deployments, terraform is deleting the old API stage without creating the new one. This especially confusing since when we check the output and .tfstate file the stage seems to have been created correctly. It's only at the time you either hit an end-point or double check the console when you can see that the stage hasn't been created.
After some testing, we have found out that if we change the stage_name we can replicate the behaviour in subsequent deployments. Thus we can reproduce this behaviour:
0.9.6
resource "aws_api_gateway_deployment" "football_api" {
lifecycle {
create_before_destroy = true
}
depends_on = [
<List of aws_api_gateway_integracion dependencies>
]
rest_api_id = "${aws_api_gateway_rest_api.football.id}"
stage_name = "${var.env}"
stage_description = "${timestamp()}"
description = "Deployed ${var.deployed}"
}
https://gist.github.com/martinezp/7662132b5f24463414ebac0a5c413128
Old stage removal, and new stage creation
Old stage removed but no new stage created even though it's apparently been created if we check the .tfstate
terraform apply
terraform apply
Hi @martinezp
I was able to reproduce the issue.
Unfortunately this happens because deleting a deployment also causes the stage to be deleted as it was initially created during the deployment. The ideal solution would be managing stage independently of deployments, but that's unfortunately not possible, because you need a deployment ID in order to create a new stage, so this seems to be a closed circle.
We don't have a good mechanism for management of "versioned" resources like API Gateway in Terraform yet. See https://github.com/hashicorp/terraform/issues/6613 for related discussion (which was then migrated to https://github.com/terraform-providers/terraform-provider-aws/issues/162)
The solution we're aiming for long-term is to have a first-class support for resource like API Gateway and allow users to manage deployments rather than be limited to a scope a single deployment. This will however take time as it requires some core changes.
I hope the explanation makes sense.
@radeksimko I can not reproduce this one till 1.39.0, I think you can close it.
Hi everyone, thanks for reporting and verifying this. Given the above report that it's no longer broken, I'm going to close the issue. If it happens again with the most recent Terraform and AWS provider releases, please open a new bug report so we can investigate. Thank you!
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!
Most helpful comment
Hi @martinezp
I was able to reproduce the issue.
Unfortunately this happens because deleting a deployment also causes the stage to be deleted as it was initially created during the deployment. The ideal solution would be managing stage independently of deployments, but that's unfortunately not possible, because you need a deployment ID in order to create a new stage, so this seems to be a closed circle.
We don't have a good mechanism for management of "versioned" resources like API Gateway in Terraform yet. See https://github.com/hashicorp/terraform/issues/6613 for related discussion (which was then migrated to https://github.com/terraform-providers/terraform-provider-aws/issues/162)
The solution we're aiming for long-term is to have a first-class support for resource like API Gateway and allow users to manage deployments rather than be limited to a scope a single deployment. This will however take time as it requires some core changes.
I hope the explanation makes sense.