v0.5.3
fix: Allow for custom_iam_policy_arns that are unknown at apply @natemccurdy (#46)
what
Replace the toset()
in the aws_iam_role_policy_attachment
resource's for_each
attribute with a map of name:ARN pairs.
why
Prior to this patch, specifying custom_iam_policy_arns
for IAM Policies that do not exist yet and would be created in the same Terraform run that creates the Lambda Execution Role would cause the following error:
│ Error: Invalid for_each argument
│
│ on .terraform/modules/foo.test_lambda/iam-role.tf line 81, in resource "aws_iam_role_policy_attachment" "custom":
│ 81: for_each = local.enabled && length(var.custom_iam_policy_arns) > 0 ? var.custom_iam_policy_arns : toset([])
│ ├────────────────
│ │ local.enabled is true
│ │ var.custom_iam_policy_arns is set of string with 3 elements
│
│ The "for_each" set includes values derived from resource attributes that cannot be determined until apply, and so Terraform cannot determine the full set of keys that will identify the instances of this resource.
│
│ When working with unknown values in for_each, it's better to use a map value where the keys are defined statically in your configuration and where only the values contain apply-time results.
│
│ Alternatively, you could use the -target planning option to first apply only the resources that the for_each value depends on, and then apply a second time to fully converge.
This is due to the ARN's of those policies not being known at apply time and the usage of toset()
in the aws_iam_role_policy_attachment
resource's for_each
parameter. As the set's values are unknown at apply time, Terraform can't create a dependency graph.
references
Similar issues with similar fixes in other CloudPosse modules:
🚀 Enhancements
fix: Add null/label context tags to the aws_lambda_function resource @natemccurdy (#44)
What
Use tags = module.this.tags
on the aws_lambda_function
resource.
Why
Prior to this, the aws_lambda_function
resource was not getting tagged at all
when passing just the null/label context into the module.
For example, this would end up with a completely untagged Lambda function even
though I am passing the context from a standard null/label declaration:
module "test" {
source = "cloudposse/lambda-function/aws"
version = "0.5.1"
function_name = "${module.this.id}-test"
attributes = ["foo"]
description = var.lambda_description
s3_bucket = var.lambda_s3_bucket
s3_key = var.lambda_s3_key
runtime = var.lambda_runtime
handler = var.lambda_handler
context = module.this.context
}
To get any tags on the lambda, the tags
attribute must be used:
module "test" {
source = "cloudposse/lambda-function/aws"
version = "0.5.1"
function_name = "${module.this.id}-test"
attributes = ["foo"]
description = var.lambda_description
s3_bucket = var.lambda_s3_bucket
s3_key = var.lambda_s3_key
runtime = var.lambda_runtime
handler = var.lambda_handler
context = module.this.context
tags = module.this.tags
}
This has a couple of problems:
- The
attributes
list is missing from the resultant set of tags. - The requirement of passing an explicit
tags
attribute is not how other CloudPosse modules work.
Outcome
- The
aws_lambda_function
resource is tagged with the implicit tags passed in viacontext
. - Tags from the
tags
variable are still present, but are now merged with the tags fromcontext
. - This module follows the convetion of other CloudPosse modules.
- People used to CloudPosse modules will have an easier time using this module.