feat: Support cloud-config content in pre-bootstrap script

[danfromtitan]

Description

Add content type to the pre-bootstrap script to allow for native cloud-config syntax.

Motivation and Context

The current implementation has hardcoded shell script content type in the cloudinit_config template resource of the node groups. Having a cloudinit_config resource should support true cloud-config syntax.

Breaking Changes

The change is backwards compatible, i.e. it sets the content type to shell script if none is provided.

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects

• I have executed pre-commit run -a on my pull request

[bryantbiggs]

thank you for the PR but we won't be introducing this change at this time. if you wish to utilize this syntax, you can try providing your own custom user data template via user_data_template_path

[danfromtitan]

if you wish to utilize this syntax, you can try providing your own custom user data template via user_data_template_path

@bryantbiggs That won't be possible because the custom user template implementation effectivelly clutters every pre- and post- user data in a shell script and makes it impossible to specify another content type. If I would go down the path you suggested, I would have to submit an even more convoluter PR which I suspect would have the same fate as this one.

[bryantbiggs]

A PR is not required to use a custom template - you simply provide a custom template. This is accompanied by supplying a custom AMI which ejects you out of any user data structure that is provided here.

I'm not sure what you mean by "clutter" - but I do hope you have read the EKS managed node group docs and are familiar with how user data coordination is handled with EKS managed node groups, users supplying custom user data that is pre-pended ahead of what the service provides, and how the use of a custom AMI effectively removes any user data prescription

[danfromtitan]

This is not about using a custom AMI, it's about the ability to run cloud-config scripts. The content type is specified outside the user template, thus using a custom user template doesn't make any difference. In the current implementation, user data is opinionated about the content type: it's gotta be a shell script.

The workaround to this is to provide an external launch template instead of having the node group module create one. The reason I didn't want to use that is, the security group of the node group that is maintained by the module cannot be attached to the external launch template (chicken&egg scenario).

[danfromtitan]

Besides, the official AWS EKS ami does support cloud-config. Providing a custom AMI doesn't solve the issue, the user data as it is handled by the user_data submodule, won't allow for any content type other that shell script.

[bryantbiggs]

after re-considering, we are going to close this request at this time. thank you

[github-actions]

I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.