AWS API Gateway Stage seems to point to old Deployment even though updated

Terraform Providers AWS
1

Using this configuration:

resource "aws_api_gateway_stage" "this" {
  stage_name           = var.stage_name
  rest_api_id          = aws_api_gateway_rest_api.this.id
  deployment_id        = aws_api_gateway_deployment.this.id
}

resource "aws_api_gateway_deployment" "this" {
  rest_api_id = aws_api_gateway_rest_api.this.id

  triggers = {
    redeployment = sha1(jsonencode([
      data.aws_iam_policy_document.this.json,
    ]))
  }

  lifecycle {
    create_before_destroy = true
  }

  depends_on = [aws_api_gateway_integration.this]
}

There seems to be an issue of the current deployment not having the latest resources policy. I know triggering the deployment has been discussed a lot, but that part is working fine. My plan shows that the policy has an update, and this triggers and update to the deployment and stage.

However, the actual resource policy is not updated in the stage. So I have to manually deploy the stage each time to get the new resource policy.

Am I missing something.

Here is the apply:

module.api_int_shadow.aws_api_gateway_rest_api_policy.this: Modifying... [id=uiqpb96816]
module.api_int_shadow.aws_api_gateway_deployment.this: Creating...
module.api_int_shadow.aws_api_gateway_rest_api_policy.this: Modifications complete after 1s [id=uiqpb96816]
module.api_int_shadow.aws_api_gateway_deployment.this: Creation complete after 1s [id=qgadwc]
module.api_int_shadow.aws_api_gateway_stage.this: Modifying... [id=ags-uiqpb96816-sit]
module.api_int_shadow.aws_api_gateway_stage.this: Modifications complete after 0s [id=ags-uiqpb96816-sit]
module.api_int_shadow.aws_api_gateway_deployment.this (deposed object 11fce76c): Destroying... [id=qictv8]
module.api_int_shadow.aws_api_gateway_deployment.this: Destruction complete after 0s

So it starts creating the deployment, before the policy has finished updating. Isn’t that an issue?

1 Like
2

Hi @theherk,

In your log output I can see that you have a deposed object for module.api_int_shadow.aws_api_gateway_deployment.this, which means that on a previous attempt Terraform tried to destroy your existing deployment but encountered an error. Terraform tracks that object as “deposed” so it can remember to plan to destroy it again on the next run.

Did this apply complete without errors? I’m wondering if that deposed object has now been cleaned up or if it continues to exist in Terraform’s state.

Regarding the question of whether the ordering of the resource policy matters, I must admit I’m not familiar enough with that part of API Gateway to say whether the policy is part of the set of behaviors covered by “deployments”, but it seems plausible.

If that’s true then you may need to add additional dependencies to the aws_api_gateway_deployment resource to help Terraform understand the relationships. For example, you could change your triggers argument to refer to aws_api_gateway_rest_api_policy.example.policy (where “example” is the name of your policy resource) instead of data.aws_iam_policy_document.this.json, and then Terraform will know that it needs to wait for the policy changes to complete before taking actions for the deployment.

Currently the deployment only depends on the construction of the policy document in Terraform’s own memory, so it doesn’t wait for the document to be persisted in the remote API first.

3

Oh boy! That makes perfect sense immediately. Relying on the policy data source instead of the actual policy is definitely a problem on my part. You always are such great help.

Yes the apply went off without issue. I’m not sure if there is always a deposed object in these cases. I’ll have to check more thoroughly. I’ll try to change the dependency, and follow up if there are additional troubles. Thank you so much.

4

Indeed changing the dependency as suggested does change the order of operations, as expected.

So my dependencies are changed to:

  depends_on = [
    aws_api_gateway_integration.this,
    aws_api_gateway_rest_api_policy.this,
  ]

and the order is now:

module.api_int_shadow.aws_api_gateway_rest_api_policy.this: Modifying... [id=uiqpb96816]
module.api_int_shadow.aws_api_gateway_rest_api_policy.this: Modifications complete after 0s [id=uiqpb96816]
module.api_int_shadow.aws_api_gateway_deployment.this: Creating...
module.api_int_shadow.aws_api_gateway_deployment.this: Creation complete after 0s [id=umkym0]
module.api_int_shadow.aws_api_gateway_stage.this: Modifying... [id=ags-uiqpb96816-sit]
module.api_int_shadow.aws_api_gateway_stage.this: Modifications complete after 1s [id=ags-uiqpb96816-sit]
module.api_int_shadow.aws_api_gateway_deployment.this (deposed object 83894674): Destroying... [id=4pj8g7]
module.api_int_shadow.aws_api_gateway_deployment.this: Destruction complete after 0s

I’m unable to verify immediately if this means the policy is correct in the stage deployment, but I suspect it is.

As an aside, the same deployment object is deposed in each run.