[Bug]: Nodegroup with LaunchTemplate always adds to Update History

[georgblumenschein]

Is there an existing issue for this?

• I have searched the existing issues

Affected Resource(s)

eks.aws.upbound.io/v1beta1 - NodeGroup
ec2.aws.upbound.io/v1beta1 - Launchtemplae

Resource MRs required to reproduce the bug

apiVersion: eks.aws.upbound.io/v1beta1
kind: NodeGroup
metadata:
  name: test-ng
spec:
  forProvider:
    clusterNameSelector:
      matchControllerRef: true
    versionSelector:
      matchControllerRef: true
    nodeRoleArnSelector:
      matchControllerRef: true
      matchLabels:
        role: nodegroup
    launchTemplate:
      - name: test-ng-lt
        version: "$Default"
    amiType: "AL2_x86_64"
    capacityType: SPOT
    instanceTypes:
      - m7a.large
    forceUpdateVersion: false
    releaseVersion: "1.29.0-20240227"
    scalingConfig:
      - maxSize: 2
        minSize: 0
        desiredSize: 0
---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: LaunchTemplate
metadata:
  name: test-ng-lt
spec:
  forProvider:
    blockDeviceMappings:
      - ebs:
        - volumeType: gp3
          volumeSize: 50
        deviceName: /dev/xvda
    monitoring:
      - enabled: true
    name: test-ng-lt
    updateDefaultVersion: true
    instanceRequirements:
      - allowedInstanceTypes:
          - m7a.large
        memoryMib:
          - min: 2048
        vcpuCount:
          - min: 2

Steps to Reproduce

1. Deploy the resources
2. Wait for the NodeGroup with the LaunchTemplate to show up in the AWS console
3. Check the update history of the NodeGroup

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

[haarchri]

yes we have the same issue with

    launchTemplate:
      - name: my-awesome-launchtemplate
        version: $Latest

[turkenf]

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)}"}

[turkenf]

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.