fix: Token password causing terraform change when no change

[flashpaper12]

‼️ PLEASE READ THIS FIRST ‼️

The direction for EKS Blueprints will soon shift from providing an all-encompassing, monolithic "framework" and instead focus more on how users can organize a set of modular components to create the desired solution on Amazon EKS. We have updated the examples to show how we use the https://github.com/terraform-aws-modules/terraform-aws-eks for EKS cluster and node group creation. We will not be accepting any PRs that apply to EKS cluster or node group creation process. Any such PR may be closed by the maintainers.

We are hitting also the pause button on new add-on creations at this time until a future roadmap for add-ons is finalized. Please do not submit new add-on PRs. Any such PR may be closed by the maintainers.

Please track progress, learn what's new and how the migration path would look like to upgrade your current Terraform deployments. We welcome the EKS Blueprints community to continue the discussion in issue #1421

What does this PR do?

🛑 Please open an issue first to discuss any significant work and flesh out details/direction - we would hate for your time to be wasted.
Consult the CONTRIBUTING guide for submitting pull-requests.

Motivation

The current example will cause a new helm release to be created, everytime terraform apply is called. This is because a new token is retrieved from the public ECR and thus causing the data.aws_ecrpublic_authorization_token.token.password to be different every time. Which will then "trick" the helm release into deploying a new version when a new version is not needed.

This change will add the public registry to the helm provider itself, rather than as a helm config of the karpenter module.

More

• [Y] Yes, I have tested the PR using my local account setup (Provide any test evidence report under Additional Notes)
• Yes, I have updated the docs for this feature
• Yes, I ran pre-commit run -a with this PR

For Moderators

• E2E Test successfully complete before merge?

Additional Notes

[FernandoMiguel]

how does this example help fixing this , since it is not functional?

[flashpaper12]

how does this example help fixing this , since it is not functional?

I'm sorry, I don't quiet understand the question. Are you saying the example was non-functional to begin with?

The issue is that because the token credentials keep changing on every apply, it means the module input would be different every time, thus causing a reapplication even though nothing has changed.

[FernandoMiguel]

And afaik that is the least worst implementation for this.
Changing the example won't help anyone, and whatever practicioners implement is going to end up like this.
Removing this from the example, will just make it harder to discover.

[flashpaper12]

Can you please elaborate? Are you saying the current karpenter example is not good?

[FernandoMiguel]

You tell me, since you are the one making this change.

[bryantbiggs]

thank you for the PR - unfortunately this is not the correct implementation. We will stick with the current implementation at this time, but users can utilize the token at the provider level in their implementations if they so choose