While create a new api deployment aws_api_gateway_deployment tries to destroy existing deployment, which errors out as Active stages pointing to this deployment must be moved or deleted

[ghost]

This issue was originally opened by @only1vinay as hashicorp/terraform#22792. It was migrated here as a result of the provider split. The original body of the issue is below.

---

In my api gateway deployment, I usually try to create a new deployment and attach it to a new versioned stage and an existing stage.

lets say I have versioned stages and a named stage 'latest' already provisioned.

1. 1.0.0 (Deployment id: abcabc)
2. 1.0.1 (Deployment id: cbacba)
3. latest (Deployment id: cbacba)

Both latest and 1.0.1 are pointing to a latest deployment. In my new Terraform run, where swagger is updated to version 1.0.2 will update the aws_api_gateway_rest_api and triggers new aws_api_gateway_deployment with stage_name='latest' and also creates a new stage '1.0.2' with this new deployment.

Terraform apply errors out saying aws_api_gateway_deployment.deployment: BadRequestException: Active stages pointing to this deployment must be moved or deleted.

But I need my old deployment existing as it is getting used in 1.0.1 stage.

If everything runs good, the new stages will look like this

1. 1.0.0 (Deployment id: abcabc)
2. 1.0.1 (Deployment id: cbacba)
3. 1.0.2 (Deployment id: aabbcc)
4. latest (Deployment id: aabbcc)

Terraform Version

0.12.8

Terraform Configuration Files

module "test_definition" {
  title                                      = "test-api"
  source                                     = "xxxx"
  api_version                                = "1.0.2"
}

resource "aws_api_gateway_rest_api" "test" {
  body        = module.test_definition.swagger
  description = "test"
  name        = module.test_definition.title
}

resource "null_resource" "update_rest_test" {
  depends_on = [null_resource.install_aws_cli]

  provisioner "local-exec" {
    command = "aws apigateway update-rest-api --rest-api-id ${aws_api_gateway_rest_api.test.id} --patch-operations op=replace,path=/minimumCompressionSize,value=10240"
  }

  triggers = {
    body        = sha256(module.test_definition.swagger)
    name        = module.test_definition.title
    rest_api_id = aws_api_gateway_rest_api.test.id
  }
}

resource "aws_api_gateway_deployment" "test" {
  description       = "${module.test_definition.title}-${module.test_definition.version}"
  rest_api_id       = aws_api_gateway_rest_api.test.id
  stage_description = "${module.test_definition.title}-${module.test_definition.version}"
  stage_name        = "latest"
  lifecycle {
    create_before_destroy = true
  }
}

resource "null_resource" "update_deployment_stage" {
  depends_on = [null_resource.install_aws_cli]

  provisioner "local-exec" {
    command = "aws apigateway update-stage --rest-api-id ${aws_api_gateway_rest_api.test.id} --stage-name ${aws_api_gateway_deployment.test.stage_name} --patch-operations op=replace,path=/*/*/logging/loglevel,value=INFO op=replace,path=/*/*/metrics/enabled,value=true"
  }

  triggers = {
    api_version           = module.test_definition.version
    deployment_stage_name = aws_api_gateway_deployment.test.stage_name
    rest_api_id           = aws_api_gateway_rest_api.test.id
  }
}

resource "null_resource" "create_versioned_stage" {
  depends_on = [null_resource.install_aws_cli]

  provisioner "local-exec" {
    command = "aws apigateway create-stage --rest-api-id ${aws_api_gateway_rest_api.test.id} --stage-name ${module.test_definition.version} --deployment-id ${aws_api_gateway_deployment.test.id} && aws apigateway update-stage --rest-api-id ${aws_api_gateway_rest_api.test.id} --stage-name ${module.test_definition.version} --patch-operations op=replace,path=/*/*/logging/loglevel,value=INFO op=replace,path=/*/*/metrics/enabled,value=true"
  }

  triggers = {
    api_version   = module.test_definition.version
    deployment_id = aws_api_gateway_deployment.test.id
    rest_api_id   = aws_api_gateway_rest_api.test.id
  }
}

Expected Behavior

Successfully create the deployment to the stage specified. Leave the old deployment as it is, instead of trying to delete it.

Actual Behavior

aws_api_gateway_deployment.deployment: BadRequestException: Active stages pointing to this deployment must be moved or deleted

Steps to Reproduce

Additional Context

The api gets deployed properly with new stage. But terraform errors out aws_api_gateway_deployment tries to destroy existing deployment, which errors out as Active stages pointing to this deployment must be moved or deleted.
So workaround is, I go to console, select the stage (1.0.1) and change its deployment to older version.

References

[ryanhartkopf]

I am having this issue as well. Currently, the only solution that has worked for me is to taint the aws_api_gateway_base_path_mapping when updating the swagger file.

See hashicorp/terraform#10674 for more details on this problem.

[trov-madisonhope]

enabling create_before_destroy fixes it. the terraform documentation doesn't make it very clear but certain cases, it's a requirement, and it appears to be one in this case.

[christhomas]

which resource needs this "create_before_destroy" lifecycle though? All of them? or just one of them?

[hdryx]

which resource needs this "create_before_destroy" lifecycle though? All of them? or just one of them?

The deployment one

[bflad]

Hi folks 👋 It looks like this was resolved above by adjusting the configuration, which would be our general recommendation in this case. This is not behavior we can turn on by default in the provider code for any resources.

We very recently adjusted the documentation for the aws_api_gateway_deployment resource to include a blue informational box at the top recommending the usage of create_before_destroy as well as updated the example usage. You may also find the new triggers argument useful too. 😄

If there is still an issue after adding create_before_destroy (and potentially using triggers), please file a new GitHub issue for any bug report or feel free to ask on the community forums where there are far more people ready to help, whereas the GitHub issues here are generally monitored only by the small set of code maintainers. 👍

[christhomas]

The problem @bflad is that it's not clear which resources need create_before_destroy, apart from just randomly applying it to objects and seeing what works.

[christhomas]

ok, I will try it next chance I get, please don't lock this ticket in the meantime, so I get a chance to reply

[ghost]

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!