-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Allow alternative user_data format in node_groups #1644
Comments
AWS provider ( v3.64.0) supports BOTTLEROCKET_x86_64 but hardcoded userdata.sh.tpl does not allow to use it. hashicorp/terraform-provider-aws#21548 |
Exactly. That is what the linked PR is designed to fix 🙂 |
This issue has been automatically marked as stale because it has been open 30 days |
/active |
This issue has been resolved in version 18.0.0 🎉 |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Is your request related to a new offering from AWS?
Yes (ish) - It relates to supporting the Bottlerocket AMI using
node_groups
.Is your request related to a problem? Please describe.
The
node_groups
module is more opinionated about theuser_data
for a node group than theworker_groups
configuration was, forcing either:sh
-based cloud-init user data.Bottlerocket (a hardened AMI designed for use as a worker node in EKS) uses raw TOML for its user data, not embedded in cloud-init or a shell.
As such, it is very easy to create an older
worker_group
based on Bottlerocket, but very labour intensive and brittle to create a newernode_group
, even when wishing to reuse all of the other Launch Template features provided in this module.Describe the solution you'd like.
I would like to see the
userdata_template_file
anduserdata_template_extra_args
(or similar) module variables replicated from the parent module to thenode_groups
module. This could easily be made to work with thecloudinit_config
resource, which already does templating. To be completely accurate, it should also be possible to set the MIME type of the resulting config file with something along the lines ofuserdata_mime_type
, or to leave it unset when needing raw user data.I would probably modify the shape of the above recommended variables to be the following, but this is just because I like nested configuration:
Describe alternatives you've considered.
The only alternative to the above, whilst still using
node_groups
, appears to be to setcreate_launch_template
tofalse
, duplicate all of the behaviour outside of the module, then pass in thelaunch_template_id
.However, this is brittle (liable to falling behind the launch configuration in this module) and hard to achieve (as many of the variables set in this module's launch templates are derived from values derived from the inner workings of the module). As such, I do not see it as a truly viable alternative.
The other alternative is to use the older
worker_groups
variable. However, this suffers from other issues that are solved bynode_groups
, taking for example the issue of worker group identification in Terraform state as an item in a list: if removing a worker group from the middle of the list, Terraform will instead see the last group in the list removed, and every group from the logically removed group onward as, instead, modified, resulting in their tear down and recreation.node_groups
solves this, but cannot currently be used due to the problem that is the subject of this Issue.The text was updated successfully, but these errors were encountered: