feat: Improve addon dependency chain and decrease time to provision addons (due to retries) #3218
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
aws_eks_cluster.this[0].name
withaws_eks_cluster.this[0].id
. The resultant value is the same, the name of the EKS cluster, but the use ofid
is important with respect to dependency management. The.name
attribute is simply a pass through of what users provide and will "return early" whereas the.id
is unique within Terraform since it is the key of the specific resource within the Terraform state map, and therefore is only made available upon success resource creation. The use of.id
ensures that any implicit dependencies are forced to wait until the value is made available. Referenceresolve_conflicts_on_create
from"OVERWRITE"
to"NONE"
whenbootstrap_self_managed_addons = false
. In the next breaking change,bootstrap_self_managed_addons
will be set tofalse
and the addons API will be used by users to deploy the addons of their choosing; removing the legacy behavior of EKS automatically deploying self-managed addons into clusters. This change will clean up the addon provisioning process where today self-managed addons are automatically deployed by EKS and then adopted by the EKS addons API (via Terraform) which causes additional time and overhead to instead deploy an "empty" EKS cluster and once the API server is ready and available (see change just above), deploy the necessary addons via the EKS addons APIAn example/test case has been supplied to demonstrate the intended behavior (order of operations output from Terraform captured below) in addition to suggestions users can implement today to improve this process. The next breaking change of the module will have these suggestions implemented within the module by default.
Motivation and Context
Breaking Changes
ToDo
s for when next breaking change occursHow Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectspre-commit run -a
on my pull requestResult of changes
Things to note in the Terraform order of operations below:
before_compute = true
) in order to ensure the daemonsets are configured correctly before nodes are provisioned.