[Bug]: aws_eks_addon fails creation with resolve_conflicts = "PRESERVE"

[z0rc]

Terraform Core Version

1.3.2

AWS Provider Version

4.36.1

Affected Resource(s)

• aws_eks_addon

Expected Behavior

Setting resolve_conflicts = "PRESERVE" should be supported in all cases.

Actual Behavior

Addon creation fails when applying this resource to new empty EKS cluster.

Relevant Error/Panic Output Snippet

╷
│ Error: error creating EKS Add-On (poc-01-cluster:vpc-cni): InvalidParameterException: Resolve conflicts option PRESERVE is not supported for operation CreateAddon
│ {
│   RespMetadata: {
│     StatusCode: 400,
│     RequestID: "2ec20228-70d6-4f9f-9c89-91115ebb3431"
│   },
│   AddonName: "vpc-cni",
│   ClusterName: "poc-01-cluster",
│   Message_: "Resolve conflicts option PRESERVE is not supported for operation CreateAddon"
│ }
│ 
│   with aws_eks_addon.vpc_cni,
│   on eks_addons.tf line 1, in resource "aws_eks_addon" "vpc_cni":
│    1: resource "aws_eks_addon" "vpc_cni" {
│ 
╵

Terraform Configuration Files

resource "aws_eks_addon" "vpc_cni" {
  cluster_name      = module.eks.eks_cluster_id
  addon_name        = "vpc-cni"
  addon_version     = "v1.11.4-eksbuild.1"
  resolve_conflicts = "PRESERVE" # keep manual changes to daemonset env vars

  service_account_role_arn = module.vpc_cni_eks_iam_role.service_account_role_arn
}

Steps to Reproduce

Create EKS cluster using aws_eks_cluster and add aws_eks_addon to it.

Debug Output

No response

Panic Output

No response

Important Factoids

According to AWS EKS API, both CreateAddon and UpdateAddon consider OVERWRITE | NONE | PRESERVE as valid string for resolveConflicts. But CreateAddon doesn't actually allow it.

Preserve – Not supported. You can set this value when updating an add-on though. For more information, see UpdateAddon.

References

https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateAddon.html#API_CreateAddon_RequestBody
https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#API_UpdateAddon_RequestBody

Would you like to implement a fix?

No

[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.

[mattburgess]

@z0rc - as your links to the documentation point out, the AWS EKS CreateAddon API doesn't support PRESERVE. Presumably, then, your original 'Expected Behaviour' of supporting that option in all cases isn't actually what you want - we obviously can't make the API support something it doesn't 😄 We can, though, try to improve the validation on the Terraform provider side so that it also rejects "PRESERVE" - that way you'll get quicker feedback that what you've asked for isn't possible.

[z0rc]

@mattburgess my use case is to have terraform code that can be applied always. I need PRESERVE to keep manual changes to EKS addon. Also I need to be able to apply terraform code when creating new cluster and addons or updating existing cluster and addons. With your proposal I need to set different resolve_conflicts depending whether addon is being created first time or updated afterwards, which contradicts terraform design philosophy.

The way I see this situation can solved is by extending resolve_conflicts to handle validation and actual apply behavior depending on whether it's first time creation or update to existing addon, something like

resolve_conflicts {
  on_create = "OVERWRITE"
  on_update = "PRESERVE"
}

[mattburgess]

@z0rc it's taken a while but I might be able to pick this up.

I like your proposal, except that changing resolve_conflicts as you've suggested would be a breaking change (because of the change from a plain string type to a map type) which is probably best avoided. Instead, we could look at deprecating use of resolve_conflicts and have the behaviour controlled by 2 new attributes, resolve_conflicts_on_create and resolve_conflicts_on_update. resolve_conflicts_on_create would only be allowed to take on the values of NONE and OVERWRITE, whereas resolve_conflicts_on_update would take all 3 values.

[jar-b]

Closed by #29555, merged to main via #31392

[github-actions]

This functionality has been released in v5.0.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

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.