Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing issues w/ userdata #28

Merged
merged 2 commits into from
Aug 30, 2020
Merged

Fixing issues w/ userdata #28

merged 2 commits into from
Aug 30, 2020

Conversation

danjbh
Copy link
Contributor

@danjbh danjbh commented Aug 30, 2020

what

After further testing, I discovered that the default userdata is being added to the end of the custom userdata we're supplying via our launch template. This causes bootstrap.sh to be called twice and creates a condition where a node group fails to provision correctly in some circumstances. And after digging further, aws_eks_node_group appears to be doing a bit of trickery w/ the launch templates under the hood, contrary to our initial expectation that the userdata we were supplying would act as an override.

We'll need to revisit this once there is more information/documentation available on the exact behavior and whether or not it's possible to completely override userdata when using aws_eks_node_group.

Anyhow, for now I propose that we just support before_cluster_joining_userdata and omit the rest of the userdata options. This will provide us with the proper tag propagation, as well as the ability to add some custom provisioning to to the node as requested by the community.

why

  • The latest version the module may not work at all for some folks unfortunately

UPDATE

After further research, I found the following in the introduction blog post for this feature...

Note that user data is used by EKS to insert the EKS bootstrap invocation for your managed nodes. EKS will automatically merge this in for you, unless a custom AMI is specified. In that case, you’ll need to add that in.

So hypothetically, if we supply our AMI configuration option (which presents it's own challenges), we should be able to override the userdata completely and supply our own kubelet arguments directly (e.g. taints). We can discuss this approach in another issue/PR, but I say for now we proceed with this PR and get the first couple bits of functionality working reliably. We'll regroup and proceed from there.

references

https://aws.amazon.com/blogs/containers/introducing-launch-template-and-custom-ami-support-in-amazon-eks-managed-node-groups/

@danjbh danjbh requested review from a team as code owners August 30, 2020 04:59
@danjbh danjbh self-assigned this Aug 30, 2020
@danjbh
Copy link
Contributor Author

danjbh commented Aug 30, 2020

/test all

@danjbh danjbh added the terraform/0.13 Module requires Terraform 0.13 or later label Aug 30, 2020
@danjbh
Copy link
Contributor Author

danjbh commented Aug 30, 2020

/test all

@danjbh danjbh merged commit ac814c6 into cloudposse:master Aug 30, 2020
xario pushed a commit to xario/terraform-aws-eks-node-group that referenced this pull request Aug 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
terraform/0.13 Module requires Terraform 0.13 or later
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants