The switch to templatefile() in 0.16 limits too much, but it can be fixed.

[Type1J]

f7d09a2

This change is not compatible with cloudinit. The template_cloudinit_config resource has been moved into its own provider with no changes other than the resource now being called just cloudinit_config. I now would need to create a static template file for the shell and options combined. The trouble is that the file must have different line endings (\r\n for header endings in the multipart mime message, and \n for newlines in the startup script). This doesn't work well in source control, and most text editors attempt to normalize line endings as well, if I prerendered it.

There are 2 possible solutions without using the deprecated template provider:

• The replace() function could be used to replace what needs replacing in the template, which is probably a brittle approach, or ...
• cloudinit could somehow be worked into the variables passed in. For example: All that's probably needed in most cases is the "text/cloud-config" part and the "text/x-shellscript" part. (NOTE: This is NOT done for Windows! Windows uses an XML like format, not cloudinit!) Here's the resource that would be added:

data "cloudinit_config" "cloudinit_userdata" {
  gzip          = false
  base64_encode = false

  part {
    content_type = "text/cloud-config"
    content      = templatefile(local.cloudinit_cloud_config_file, local.cloudinit_cloud_config_args)
  }

  part {
    content_type = "text/x-shellscript"
    content      = templatefile(local.cloudinit_shellscript_file, local.cloudinit_shellscript_args)
  }
}

Until something like that is implemented, I'm stuck on version 15.2 of this module.

[daroga0002]

doesnt you can add own customization into pre_userdata or additional_userdata inputs?

[Type1J]

In the case of Linux cloudinit is more than just the first-run startup script, but pre_userdata and additional_userdata are both within the startup script. I need to set the startup script to be executed on each run, which I've been doing in version 15.2 of this module, and if-ing out the script as it is in the template.

In the case of Windows, to use <persist>true</persist>, which, as with Linux, I must do in my situation, the pre_userdata and additional_userdata are inside the <powershell>...</powershell> area, so I can't add it. I tried, closing powershell, and reopening it, but EC2Launch didn't seem to like it. Also, the existing script will need to be if-ed out after the first run.

[daroga0002]

but you can just do in pre_userdata something like:

echo "/opt/something/script" > /etc/init.d/S99start

I still dont understand your use case, maybe show me on example what you trying to achieve

[Type1J]

I understand that you're trying to understand my specific usecase, and I know that I can use the first boot script to get the functionality that I want. However, the bits of functionality other than the first boot script in user_data by cloudinit and EC2Launch are considered the canonnical way of configuring an EC2 instance, not just hacks in the first boot script.

I don't understand the rationale of blocking all of the functionality in user_data for cloudinit and EC2Launch other than (only some parts) of the first boot script. I do understand that the template provider is deprecated, and should be removed. I'm proposing that replace() be used instead of templatefile(), which would allow a string of the actual user_data payload to be provided instead of a file. The replace() function is part of the Terraform language, and it could be used instead of templatefile() to restore the functionality preaent in this module as 15.2 and removed in 16.0.

[Type1J]

I haven't given a PR because of 2 reasons:

1. It's a breaking change. It would't break a user upgrading from version 15.2 of this module, but it would be a breaking change from the latest version of this module.
2. The changes are small and fairly trivial.

Would it help if I made one?

[daroga0002]

please open a PR and this will be discussed by maintainers as of now I dont clearly understand what we are trying to address

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Type1J]

Not stale

[daroga0002]

could you open a PR to show what is about this issue?

[Type1J]

@daroga0002 Yes. I plan to do so. I'll link it to this issue when I do.

[github-actions]

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

[Type1J]

Not stale

[github-actions]

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

[Type1J]

Not stale

[antonbabenko]

This issue has been resolved in version 18.0.0 🎉

[github-actions]

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.