[main] Fix inconsistent plan issue with EKS launch template

[krunalhinguu]

Issue:

#730

Problem

The Rancher2 provider does not reconcile computed launch template version values properly during Terraform runs. When the launch template version changes (e.g., due to new AMI or configuration updates), Terraform’s plan phase uses a default or stale version (0), but the apply phase sees the actual updated version (e.g., 4). This mismatch causes the provider to report an invalid new value error and fail the apply.

Solution

The issue was resolved by updating the Rancher2 Terraform provider to mark the launch_template.version field as computed = true and removing the default value (default = 1).

This change ensures that Terraform correctly waits for the actual launch template version value to be known during the apply phase, instead of relying on a hardcoded default or outdated value from the plan phase.

With this fix, the provider can now handle dynamic version changes from the launch template (such as when a new version is triggered by configuration changes), preventing inconsistent plans and apply failures.

Testing

Manual Testing

• Created an EKS cluster using Rancher and Terraform with launch templates for node groups.
• Updated the launch template to trigger a new version.
• Verified that Terraform successfully planned and applied the changes without errors.
• Checked the AWS console and Rancher UI to confirm the node groups used the expected launch template version.
• Destroyed and recreated the cluster to ensure reproducibility.

Automated Testing

No automated tests were added, as the fix primarily addresses a runtime inconsistency in Terraform provider behavior rather than a logic bug.

QA Testing Considerations

• Verify EKS cluster provisioning via Terraform with launch template versions explicitly set.
• Confirm that updating the launch template version triggers the correct node group updates without plan/apply errors.
• Test cluster upgrades involving node group changes to ensure launch template versions remain consistent.
• Validate Rancher UI correctly displays node group configurations and launch template details.

Regressions Considerations

• The fix addresses only the launch template version handling and should not impact unrelated Rancher or EKS features.
• High chance of regressions in scenarios where launch templates are used with EKS node groups, if the version is omitted or incorrectly specified.
• Low risk of regressions for clusters not using launch templates or unmanaged via Terraform.

[matttrach]

Please sign your commits with a verified key.

[matttrach]

Since Name and Version are required, is it possible for them to be nil here? What happens if you try to leave them empty?

[krunalhinguu]

they should always be set, but I left the nil checks in just to be safe in case Rancher ever returns them unset. If we’re confident they’ll always come back populated, I can strip those out too, but I figured better to be defensive.

[matttrach]

This is a weird one.
What is the result of removing this? Isn't 'p' the value of the plan at this point?
If so, I would expect this to affect the create function.
I also see that this is the only argument that potentially updates the plan, so maybe this was a bug all along?
This also eliminates 'p' in the function, so we should remove that argument and remove the 'v' in the parent function, right?

[krunalhinguu]

Yeah, that makes sense. looks like pulling values from p was what caused the plan/state mismatch we were seeing with the version. Since we’ve marked id, name, and version as required now, I agree we don’t need to merge anything from the plan, so I’ll clean that up and remove the p argument from both the function and the parent call.

[matttrach]

Targeting v9 and v8 per #730

[mjura]

Please use one of the following prefixes: "fix:", "feature:", "feat:", "refactor!:", "feature!:", or "feat!:".
This enables release-please to automatically determine the type of release (major, minor, patch) based on the commit message.
update the condition to check for nil in version

[krunalhinguu]

@mjura I have updated the message.