-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
aws_instance: allow providing user data as base64 #850
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except one nitpick in tests this LGTM.
aws/resource_aws_instance_test.go
Outdated
|
||
// We repeat the exact same test so that we can be sure | ||
// that the handling of the user_data and user_data_base64 | ||
// distinction doesn't cause diff weirdness. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this happens by default for every single test, so the second step is redundant:
https://github.com/hashicorp/terraform/blob/master/helper/resource/testing_config.go#L92-L105
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh yes, of course. This was something I inherited and tweaked from another nearby test, but I forgot that it's not necessary here. (The other test was doing it specifically to test some of the weird behavior we do to prevent double-base64-encoding, which isn't true here.)
221b4b2
to
945d9e3
Compare
Providing base64 directly is convenient when it must be set to something that isn't valid UTF-8, such as the gzipped payloads often passed to cloud-init for more complex setups. Passing binary data directly via Terraform attributes is not safe because only UTF-8 strings can be stored in the state file. This is therefore intended for use in conjunction with the base64 encoding mode of template_cloudinit_config to enable gzip data to be passed safely to the EC2 data without corruption as it passes through Terraform.
945d9e3
to
df158da
Compare
These typos were preventing this test from being included when filtering tests by prefix.
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
Providing base64 directly is convenient when it must be set to something that isn't valid UTF-8, such as the gzipped payloads often passed to cloud-init for more complex setups.
Passing binary data directly via Terraform attributes is not safe because only UTF-8 strings can be stored in the state file. This is therefore intended for use in conjunction with the base64 encoding mode of
template_cloudinit_config
to enable gzip data to be passed safely to the EC2 data without corruption as it passes through Terraform.For more information, see the discussion at hashicorp/terraform#14314, which was later migrated to #754.
This first change deals only with
aws_instance
. Similar changes will be needed foraws_launch_configuration
andaws_lightsail_instance
later, for the same reasons.