Terraform version: 0.9.3
I know this issue has been discussed time and again (Ex: #12570) and that if a module has a map variable and has interpolation inside this map variable, count inside a module results in value of 'count' cannot be computed.
What puzzles me is that this error occurs when terraforming a new environment but not any existing environment!
I recently migrated a bunch of environments from 0.7.13 to 0.9.3 and I get it when I terraform an environment for the first time but not on any of the existing environments.
example config:
module "my-lambda-function" {
source = "../terraform_modules/my-awesome-lambda-module/"
################################################
# LAMBDA FUNCTION CONFIGURATION #
service_name = "someService"
function_name = "someFunction"
handler = "index.handler"
memory_size = 256
timeout = 180
cloudwatch_log_subscription {
enable = 1
destination_arn = "${module.lambda-elk-logging.lambda_arn}"
filter_pattern = "[timestamp=*Z, request_id=\"*-*\", event]"
}
queue = ["some-sqs-queue"]
sns_topic = ["some-sns-topic"]
# #
################################################
account_id = "${var.ct_account_id}"
region = "${var.region}"
role = "${aws_iam_role.lambda.arn}"
subnet_ids = ["${aws_subnet.private.id}"]
security_group_ids = ["${aws_default_security_group.ct-backend-network-default-sg.id}"]
}
Inside the module:
:
:
:
resource "aws_cloudwatch_log_subscription_filter" "lambda_cloudwatch_subscription" {
count = "${lookup(var.cloudwatch_log_subscription, "enable", 0)}"
name = "${var.function_name}"
log_group_name = "/aws/lambda/${var.function_name}"
filter_pattern = "${lookup(var.cloudwatch_log_subscription, "filter_pattern")}"
destination_arn = "${lookup(var.cloudwatch_log_subscription, "destination_arn")}"
depends_on = ["aws_cloudwatch_log_group.lambda_log_group"]
}
:
:
:
Hi @Puneeth-n!
When Terraform says "computed" here it means a value that isn't known until its associated resource is created. It works on a subsequent run because the resource has already been created by then and so the value is known.
There is an extra tricky thing in your case: although the enable key in your map is not computed, any computed element in a map causes the entire map to be treated as computed.
Currently you can work around this by using the -target argument to force Terraform to create the referenced resource first, and then a subsequent run will have the value populated when needed.
You could also address this in your specific situation by flattening that map into three separate variables, thus preventing the computed nature of one from impacting the others.
In the long term we will fix this with something like #4149. We are slowly making progress towards that via core refactoring to enable it. That change will make Terraform automatically detect that the change must be made in multiple passes and work through it automatically.
Since that other issue is already representing that work, I'm going to close this. Thanks for opening this issue!
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Hi @Puneeth-n!
When Terraform says "computed" here it means a value that isn't known until its associated resource is created. It works on a subsequent run because the resource has already been created by then and so the value is known.
There is an extra tricky thing in your case: although the
enablekey in your map is not computed, any computed element in a map causes the entire map to be treated as computed.Currently you can work around this by using the
-targetargument to force Terraform to create the referenced resource first, and then a subsequent run will have the value populated when needed.You could also address this in your specific situation by flattening that map into three separate variables, thus preventing the computed nature of one from impacting the others.
In the long term we will fix this with something like #4149. We are slowly making progress towards that via core refactoring to enable it. That change will make Terraform automatically detect that the change must be made in multiple passes and work through it automatically.
Since that other issue is already representing that work, I'm going to close this. Thanks for opening this issue!