Closed georgblumenschein closed 22 hours ago
yes we have the same issue with
launchTemplate:
- name: my-awesome-launchtemplate
version: $Latest
Hello folks,
Thank you for bringing up this issue. It can be reproducible with the latest provider version:
DEBUG provider-aws Diff detected {"uid": "604ae2df-0141-4a96-890f-54dff549d3a4", "name": "sample-eks-ng-ft", "gvk": "eks.aws.upbound.io/v1beta1, Kind=NodeGroup", "instanceDiff": "*terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{\"launch_template.0.version\":*terraform.ResourceAttrDiff{Old:\"1\", New:\"$Latest\", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, RawConfig:cty.NilVal, RawState:cty.NilVal, RawPlan:cty.NilVal, Meta:map[string]interface {}(nil)}"}
Hi folks, after doing some investigation on this issue:
As stated in the Terraform document, when we give $Default
or $Latest
values to the launchTemplate.version
field, diff occurs as expected.
During reading, the version number comes as a numerical value and since we set launchTemplate.version: $Latest
, it enters a continuous update loop.
After discussing the issue with the team, we realized there is no easy solution.
If we write a CustomDiff
function to delete the diff, it works, and the resource gets rid of the update loop. But this causes the launchTemplate.version
field to lose its functionality and the API to work outside expectations.
For example, let's set launchTemplate.version: $Latest
, and after creating the NodeGroup
resource, let's create a new version of LaunchTemplate
. Since we deleted the diff for the field, the launchTemplate.version
value will remain the same, and its functionality will be disrupted.
I haven't tried it, but as mentioned in the document, instead of using $Default
or $Latest
values, we can patch the latestVersion
or defaultVersion
values in the status of the LaunchTemplate
resource for the launchTemplate.version
field by using compositions. If the LaunchTemplate
resource is not managed with Crossplane, import the resource by setting managementPolicies: ["Observe"]
and patch the field.
Here, our best solution would be to prevent giving $Latest
and $Default
values to the launchTemplate.version
field.
Is there an existing issue for this?
Affected Resource(s)
eks.aws.upbound.io/v1beta1 - NodeGroup ec2.aws.upbound.io/v1beta1 - Launchtemplae
Resource MRs required to reproduce the bug
Steps to Reproduce
What happened?
Both with the $Default and the $Latest flag for the LaunchTemplate version the update history gets spammed to the point where "429: Too many Requests" on loading is returned.
I would expect that since the Default/Latest version of the LaunchTemplate is "1", it should count as synced.
Workaround: Have the version as String, so e.g. "1" as version for the LaunchTemplate
Relevant Error Output Snippet
No response
Crossplane Version
1.16.0
Provider Version
1.5.0
Kubernetes Version
1.29
Kubernetes Distribution
EKS
Additional Info
No response