Impossible to loop in lambda_function inside aws_s3_bucket_notification

[JulesDT]

Terraform Version

Terraform v0.9.4

Affected Resource(s)

• aws_s3_bucket_notification

Terraform Configuration Files

Two different syntax tested (first one valid doing the somehow expected behavior but not the wanted behavior, second one being the one we want that doesn't exist)

1. First Syntax

resource "aws_s3_bucket_notification" "bucket-notification-loop" {
  count  = "${length(var.lambdas_list)}"
  bucket = "${data.terraform_remote_state.s3.bucket_id}"

  lambda_function {
    lambda_function_arn = "${element(aws_lambda_function.create-lambdas.*.arn, count.index)}"
    events              = ["s3:ObjectCreated:*"]
    filter_prefix       = "${var.lambdas_prefix_list[element(aws_lambda_function.create-lambdas.*.id, count.index)]}"
  }
}

2. Second Syntax

resource "aws_s3_bucket_notification" "bucket-notification-loop" {
  bucket = "${data.terraform_remote_state.s3.bucket_id}"

  lambda_function {
    count  = "${length(var.lambdas_list)}"
    lambda_function_arn = "${element(aws_lambda_function.create-lambdas.*.arn, count.index)}"
    events              = ["s3:ObjectCreated:*"]
    filter_prefix       = "${var.lambdas_prefix_list[element(aws_lambda_function.create-lambdas.*.id, count.index)]}"
  }
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

I would expect each lambda to be added to the bucket notification.

Actual Behavior

Actually, because aws_s3_bucket_notification is unique for each bucket, each loop iteration rewrites the iteration before.
The second syntax just says that count is an unknown parameter for lambda_function.

Steps to Reproduce

1. terraform apply --parallelism=1

Important Factoids

account-admin role is used so everything should be fine

References

• Issue aws_s3_bucket_notification - lambda - append new instead of deleting all previous #11536 is talking about something similar but yet different

Thanks for the help, I am still available for precisions if necessary

[jonaf]

I have exactly this use-case but for a separate purpose: I have a Cloudfront distribution, in which I need about 30 different path patterns with identical caching behavior. I would like to be able to simply say count = 30 and iterate over a var that is a list of my path patterns. Instead, it looks like I'm going to have to handroll all of these, resulting in an extremely long and confusing Terraform configuration.

Are there any possible workarounds at this time?

[jonaf]

Since Terraform configurations are HCL, and it's pretty easy to convert HCL to JSON and back, I'm thinking that writing a small script to generate the Terraform configuration is my only recourse (other than backpedaling and going back to Cloudformation).

What I did was create a file, which was the list of path names I needed, and then mutate a partial Terraform configuration (a valid portion of the Terraform configuration for the "cache behaviors" section), and append all of them to a file. Finally, I dropped the (very long) result into the Terraform configuration. This was easier than handwriting it, but still results in a very long template. I'm thinking I might be able to create a module for the cache behaviors or something, so I can at least put all of the generated code in a separate file so that the original Terraform configuration is a little easier to digest.

I used https://github.com/kvz/json2hcl to serde JSON/HCL.

cat one-value-per-line.txt | while read pattern ; do cat partial-tf-config.tf | json2hcl -reverse | jq '.cache_behavior[].path_pattern = "'$pattern'"' | json2hcl | tee -a generated-config.tf ; done

terraform fmt generated-config.tf

[apparentlymart]

Hi @JulesDT! Sorry for the long silence here.

This issue is covering the same use-case as #7034, which we've now resolved due to a new feature in master ready for the forthcoming v0.12.0 release. I left a comment over there showing how the new feature can be used.

Thanks for reporting this, and sorry again for the delay in responding.

[ghost]

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.