[Bug]: timeouts block of aws_eks_addon does not support for_each loop

[jaygridley]

Terraform Core Version

1.5.7

AWS Provider Version

5.33.0

Affected Resource(s)

• aws_eks_addon

Expected Behavior

When specifying timeouts for aws_eks_addon and using for_each on the resource, timeouts should support specifying a value for timeouts.create, timeouts.update and timeouts.delete using each.value.

Actual Behavior

Terraform is producing an error when using each.value for timeouts.create, timeouts.update and timeouts.delete.

Relevant Error/Panic Output Snippet

╷
│ Error: Error parsing "create" timeout: time: unknown unit "D" in duration "74D93920-ED26-11E3-AC10-0800200C9A66"
│ 
│   with aws_eks_addon["aws-cni"],
│   on main.tf line 21, in resource "aws_eks_addon" "this":
│  21: resource "aws_eks_addon" "this" {
│ 
╵

Terraform Configuration Files

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "4.0.0"

  name               = "vpc"
  cidr               = "10.0.0.0/16"
  azs                = ["eu-central-1a", "eu-central-1b"]
  public_subnets     = ["10.0.101.0/24", "10.0.102.0/24"]
  enable_nat_gateway = true
}

module "eks_cluster" {
  source  = "cloudposse/eks-cluster/aws"
  version = "2.3.0"

  region     = "eu-central-1"
  subnet_ids = module.vpc.public_subnets
  vpc_id     = module.vpc.vpc_id
  name       = "example"
  kubernetes_version = "1.26"
}

resource "aws_eks_addon" "this" {
  for_each = {
    vpc-cni = "v1.15.5-eksbuild.1"
  }

  cluster_name  = module.eks_cluster.eks_cluster_id
  addon_name    = each.key
  addon_version = each.value

  timeouts {
    create = try(each.value.create_timeout, "30m")
  }
}

Steps to Reproduce

1. Add AWS VPC
2. Add AWS EKS cluster
3. Add AWS EKS managed addon, i.e. aws-cni using aws_eks_addon resource
4. Add for_each to the aws_eks_addon resource
5. Add timeouts to the aws_eks_addon resource and use each.value for timeouts.create
6. Run Terraform plan -> this will produce the error

Debug Output

No response

Panic Output

No response

Important Factoids

• When the addon is already installed, adding timeouts to the resource do NOT cause the error.
• Not using each.value in timeouts block do NOT cause the error.
• Value 74D93920-ED26-11E3-AC10-0800200C9A66 is Terraform magic string for an unknown value.

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[acwwat]

Looking at your example (formatted for readability):

resource "aws_eks_addon" "this" {
  for_each = {
    vpc-cni = "v1.15.5-eksbuild.1"
  }

  cluster_name  = module.eks_cluster.eks_cluster_id
  addon_name    = each.key
  addon_version = each.value

  timeouts {
    create = try(each.value.create_timeout, "30m")
  }
}

The map used in the for_each loop has the add-on version string as a value and not an object with a create_timeout attribute. However, I would expect that the default value in the try function be used instead of failing with that weird error.

Could you please try to provide a timeout properly in the map and see if it at least works? For example:

resource "aws_eks_addon" "this" {
  for_each = {
    vpc-cni = {
      version        = "v1.15.5-eksbuild.1"
      create_timeout = "45m"
    }
  }
  cluster_name  = module.eks_cluster.eks_cluster_id
  addon_name    = each.key
  addon_version = each.value.version

  timeouts {
    create = try(each.value.create_timeout, "30m")
  }
}

[acwwat]

To see whether this is a more general problem, I created another test case using aws_security_group based on the given example. I am running Terraform v1.6.3 and AWS provider v5.31.0. I am able to apply the configuration successfully, so perhaps it's a more specific problem to aws_eks_addon.

resource "aws_security_group" "this" {
  for_each = {
    "one" = "First security group"
    "two" = "Second security group"
  }
  name        = each.key
  description = each.value
  vpc_id      = "<replace_with_your_vpc_id>"
  timeouts {
    create = try(each.value.create_timeout, "10m")
  }
}

[jaygridley]

Adding create_timeout into object attributes does not help. But I was checking the behavior in Terraform 1.6.3 and the issue is gone in this version. I am just wondering what changed between 1.5.7 and 1.6.3 related to this issue.

[justinretzolk]

Hey y'all 👋 Thanks for taking the time to report this, and for the continued conversation around it! With the last update of the behavior changing between Terraform versions, I'm tempted to direct this towards the Terraform repository to have the Terraform Core team look into it, and close this issue out, since this seems more like a Core behavior than something the AWS Provider could control. I'm assuming that the AWS Provider version was static since you didn't mention it, but definitely correct me if I'm wrong there.

That said, given that it looks like it was fixed in more recent versions of Terraform, it may have been a known issue that's since been fixed. From a quick look around, the only thing that seemed maybe related was hashicorp/terraform#34096 and the related HCL PR hashicorp/hcl#634 (heavy emphasis on "quick look" and "maybe related" 🙂), which was included in 1.6.2.

Does closing this feel like an agreeable of action to you @jaygridley?

[jaygridley]

Hello @justinretzolk, I am fine with closing this one. I do agree with you that this originates more in Terraform Core than in AWS Provider. I might raise it with the Core team, but as this seems to be fixed in more recent versions I am being non-optimistic it will get addressed in a backward manner mostly due to license changes between the versions.