Fix for EKS AMI type
What does this MR do?
Follow up from !1057 (merged)
MR fixes EKS AMI Type to always be correctly set to CUSTOM
as it should be when using Launch Templates. When this isn't set node's cannot join the cluster and it enters a failed state.
This was a small miss due to a compound of factors:
- Terraform does not provide drift detection for this setting if not set
- In Terraform AWS 4.x provider this looked to typically be set to
CUSTOM
by default for some reason - In Terraform AWS 5.x provider this appears to now be correctly set to
AL2_x86_64
by default - This was assumed to be correct then for Launch Templates as we do typically use AL2 in them anyways and to only set
CUSTOM
when using a truly custom AMI - However this is not the case. Any Launch Template AMI, even if the default AL2, looks to require
CUSTOM
set as we refer to it directly now via it's image ID instead of just asking AWS for the latest version. AMI Type is not just the "classification" of AMI as suggested in docs but actually the OS image type AWS EKS should use for the cluster from it's AMI catalog. - As such, switching to only set
ami_type
when a custom AMI was given was causing a drift issue on existing environments whereCUSTOM
was already set and leading to failures so setting toCUSTOM
always is correct here.
Related issues
Relates #689 (closed)
Author's checklist
When ready for review, the Author applies the workflowready for review label and mention @gl-quality/get-maintainers
:
- Merge request:
-
Corresponding Issue raised and reviewed by the GET maintainers team. -
Merge Request Title and Description are up-to-date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline -
MR has no new security alerts in the widget from the Secret Detection
andIaC Scan (SAST)
jobs.
-
- Code:
-
Check the area changed works as expected. Consider testing it in different environment sizes (1k,3k,10k,etc.). -
Documentation created/updated in the same MR. -
If this MR adds an optional configuration - check that all permutations continue to work. -
For Terraform changes: set up a previous version environment, then run a terraform plan
with your new changes and ensure nothing will be destroyed. If anything will be destroyed and this can't be avoided please add a comment to the current MR.
-
-
Create any follow-up issue(s) to support the new feature across other supported cloud providers or advanced configurations. Create 1 issue for each provider/configuration. Contact the Quality Enablement team if unsure.
Edited by Grant Young