Data source used in logging config causes logging: should be a list during validation

[brainsik]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.11.7
+ provider.aws v1.28.0
+ provider.template v1.0.0

Affected Resource(s)

• aws_s3_bucket

Terraform Configuration Files

data "aws_iam_account_alias" "current" {}

variable "bucket" {
  default = "my-bucket"
}

variable "logging_bucket" {
  default = "my-logging-bucket"
}

locals {
  bucket_id = "${format("%s-%s", data.aws_iam_account_alias.current.account_alias, var.bucket)}"

  logging_config = {
    enabled = [{
      target_bucket = "${var.logging_bucket}"
      target_prefix = "s3/${local.bucket_id}/"
    }]

    disabled = []
  }
}

resource "aws_s3_bucket" "private_bucket" {
  bucket  = "${local.bucket_id}"
  logging = "${local.logging_config["enabled"]}"
}

Debug Output

https://gist.github.com/brainsik/d0d07a0a48cdbd4ef7dbfba26e581efb

Panic Output

N/A

Expected Behavior

Terraform should validate.

Actual Behavior

Error: aws_s3_bucket.private_bucket: logging: should be a list

Steps to Reproduce

1. terraform validate

If you replace data.aws_iam_account_alias.current.account_alias with a non-data source, then everything works fine.

Important Factoids

N/A

References

• logging: should be a list error when aws_s3_bucket resource has local variables in the logging #5037
• Unable to pass "type: List" variables from data source to modules terraform#17837

[bflad]

Hi @brainsik 👋

Are you able to workaround this by adjusting your resource definition to the below?

resource "aws_s3_bucket" "private_bucket" {
  bucket  = "${local.bucket_id}"
  logging = ["${local.logging_config["enabled"]}"]
}

There can be some oddities with the configuration language when working with computed values inside complex types. You might want to check the Terraform core repository for similar issues and other possible resolutions or workarounds.

This classification of configuration issue might be fixed or manifest differently in the upcoming Terraform 0.12 release, as underlying configuration language for Terraform (HCL) will support much richer type information as well as null arguments.

[brainsik]

Hi, @bflad. I tried wrapping that line in [] (as you suggested) as well as a bunch of other things to try to work around type issues, but no dice. It seems like the type error is maybe a red herring for something else going on underneath.

[bflad]

Hi again @brainsik 👋

Since the last time we discussed this, Terraform 0.12 was released, which has a few important and related changes with regards to this situation:

• Richer data type support throughout
• Better error messaging with type mismatches and configuration source information for these errors
• No longer supports setting configuration blocks via =, e.g. you must use the dynamic support instead

We would suggest upgrading (if you haven't already) and checking out the situation again. Since we will very shortly be no longer supporting Terraform 0.11, I'm going to opt to close this issue. If this is still an issue in Terraform 0.12, please file a new issue and we can take another look.

If you're looking for general assistance, please note that we use GitHub issues in this repository for tracking bugs and enhancements with the Terraform AWS Provider codebase rather than for questions. While we may be able to help with certain simple problems here it's generally better to use the community forums where there are far more people ready to help, whereas the GitHub issues here are generally monitored only by a few maintainers and dedicated community members interested in code development of the Terraform AWS Provider itself.

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!