[Bug]: LaunchTemplateVersions are being created with zero changes to the actual spec

[rudimk]

Is there an existing issue for this?

• I have searched the existing issues

Affected Resource(s)

• ec2.aws.upbound.io/v1beta1 - LaunchTemplate

Resource MRs required to reproduce the bug

apiVersion: ec2.aws.upbound.io/v1beta1
kind: LaunchTemplate
metadata:
  name: rudimk-sandbox-prometheus-worker-group2024031306373753250000001c
  annotations:
    crossplane.io/external-name: lt-0c6b0d243a829bd82
spec:
  deletionPolicy: Orphan
  forProvider:
    region: us-east-2
  providerConfigRef:
    name: 2591-rudimk-sandbox

Steps to Reproduce

1. Create a new LaunchTemplate / import an existing one into Crossplane. After doing so, make no changes.
2. Every 30 odd seconds, note the events being logged in the LaunchTemplate.
3. Check launch template version history on the AWS console / CLI.

You'll see the versions increment every minute or so.

What happened?

Apparently the provider ends up running a reconciliation loop(I've used Cluster API a lot so pardon the parlance) where it will create a fresh LaunchTemplateVersion even if the original LaunchTemplate on Crossplane hasn't been modified. This is fairly unexpected behaviour, since the whole idea behind versioning is to have some semblance of change across every version. Versions with no changes between them make it a lot more harder to track what actually may have changed. In addition, fairly certain AWS was going to either throw a 429 at some point / blacklist my credentials thinking I'm a malicious actor.

Relevant Error Output Snippet

No errors per se.

Crossplane Version

1.17.1-up.1

Provider Version

1.15.0

Kubernetes Version

1.31

Kubernetes Distribution

Kind

Additional Info

Related issue - #105

[rudimk]

Was thinking about this..and I suspect this may be happening because I've only imported a launch template, but I didn't specify a corresponding defaultVersion and/or latestVersion, which makes Crossplane go into this loop. Will try bringing in the versions into a Managed Resource and see if that fixes this.

[rudimk]

Ach couldn't wait to try this. So turns out one can't import the latest version into a MR(no field for that) so I added defaultVersion to the MRs, and imported them. There was a bump of two launch template versions - I'm guessing that's because Crossplane adds template tags? But it's been 5+ mins now and the latest versions on AWS haven't changed beyond the two-version bump so I think this is good! I can always set updateDefaultVersion in the MRs to ensure that if I import launch templates / make changes to MRs, the versioning will stay consistent.

While I'd def like to help document this - I understand every MR has some idiosyncrasy or the other and I'm not sure what trying to document all these scenarios would like. In any case, this bug report - since it's no longer a bug - can be closed.

[rudimk]

Actually there is an interesting side effect. To import a launch template and not have the versions go haywire, I need to import the default version in. I'd also like to ensure that if I subsequently make changes to the launch template, the default version's also updated - which is what updateDefaultVersion does. But apparently that clashes with defaultVersion, per https://marketplace.upbound.io/providers/upbound/provider-aws-ec2/v1.15.0/resources/ec2.aws.upbound.io/LaunchTemplate/v1beta1#doc:spec-initProvider-updateDefaultVersion. What would the best way forward be, here?

[rudimk]

Sorry for the spam - trying to get to the bottom of this because I wish to import some live production clusters using these launch templates and I'd hate to foul things up. As noted in the previous comment - per the provider docs updateDefaultVersion and defaultVersion don't work together. However - after successfully importing the launch template into a managed resource by specifying a defaultVersion, I then edited the managed resource to include the updateDefaultVersion flag(set to true). That triggered another two launch template versions, but luckily no more version bumps after that. The version is now stable - so perhaps this means these two parameters work well together only if one's importing an existing launch template?

Here's the updated ManagedResource for reference:

apiVersion: ec2.aws.upbound.io/v1beta1
kind: LaunchTemplate
metadata:
  name: rudimk-sandbox-worker-group-120240313063737510300000018
  annotations:
    crossplane.io/external-name: lt-014959c347434488e
spec:
  deletionPolicy: Orphan
  forProvider:
    region: us-east-2
    defaultVersion: 842
    updateDefaultVersion: true
  providerConfigRef:
    name: 2591-rudimk-sandbox