terraform-aws-datadog
terraform-aws-datadog copied to clipboard
scribd
Error: Invalid count argument (Due to S3 resources not yet created at apply time)
The count logic here is relying on resources pre-existing with known outputs:
https://github.com/scribd/terraform-aws-datadog/blob/b0c3afedc2eb0e50a995ae352f713a3e0b613767/logs_monitoring_cloudtrail.tf#L3
https://github.com/scribd/terraform-aws-datadog/blob/b0c3afedc2eb0e50a995ae352f713a3e0b613767/logs_monitoring_cloudtrail.tf#L13
For example, If comment out the module instantiation, create my s3 bucket, then uncomment the module I can deploy (as the s3 bucket outputs are known beforehand).
If I attempt a DR deployment with the bucket and module instantiation in the same workspace I get the below errors;
Error: Invalid count argument
on .terraform/modules/datadog/logs_monitoring_cloudtrail.tf line 3, in resource "aws_lambda_permission" "allow-ctbucket-trigger":
3: count = var.cloudtrail_bucket_id != "" ? 1 : 0
The "count" value depends on resource attributes that cannot be determined
until apply, so Terraform cannot predict how many instances will be created.
To work around this, use the -target argument to first apply only the
resources that the count depends on.
Error: Invalid count argument
on .terraform/modules/datadog/logs_monitoring_cloudtrail.tf line 13, in resource "aws_s3_bucket_notification" "ctbucket-notification-dd-log":
13: count = var.cloudtrail_bucket_id != "" ? 1 : 0
The "count" value depends on resource attributes that cannot be determined
until apply, so Terraform cannot predict how many instances will be created.
To work around this, use the -target argument to first apply only the
resources that the count depends on.
Switching to for_each would be the solution but of course lose backwards compatibility.
I am guessing the current cloudtrail integration expects a static bucket id value @jim80net ? @russmac what's the source of your cloudtrail_bucket_id?
@houqp an s3 bucket resource created within the same workspace. The reference var.cloudtrail_bucket_id is an output from that resource so its not known at compile time which is what causes the error.
If the s3 bucket is created using any other method (manually, -target, commenting out this module, separate workspace) the error does not occur.
Got it, could you send a PR so we can continue the discussion over there? I think it's ok to break backwards compatibility with another major release as long as it's the right fix.