Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

value of 'count' cannot be computed #13980

Closed
Puneeth-n opened this issue Apr 26, 2017 · 2 comments
Closed

value of 'count' cannot be computed #13980

Puneeth-n opened this issue Apr 26, 2017 · 2 comments

Comments

@Puneeth-n
Copy link
Contributor

Puneeth-n commented Apr 26, 2017

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"]
}

:
:
:
@apparentlymart
Copy link
Contributor

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!

@ghost
Copy link

ghost commented Apr 13, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants