provider/aws: Add user_data_not_updatable for EC2

[wjam]

Allow instances to have user data that might change over time but don't need to replace the instance when it occurs.

The purpose of this PR is to just solve a specific part of the problems found with the ignore_changes field (#5627).
This PR is aimed at allowing EC2 instances to have a cloud init script which changes on every terraform run, for example if it contained a one-time token, and not have the EC2 instances destroyed and recreated every time terraform is run.

@nickithewatt @phinze

[nickithewatt]

Awesome thanks @wjam :)
@phinze Not sure if you remember but we had a chat at HashiConf EU about introducing this alternative version of the user_data field for the aws_instance resource to workaround this specific case? In any case this PR from Will is directly related to this :)

[phinze]

I do indeed! We're sprinting to finish up the laaaaaast bits of 0.7.0, but I'll add this to the list of fast followers to consider in v0.7.1 👍

Thanks for the PR @wjam!

[nickithewatt]

Thanks @phinze :)

[wjam]

@phinze Any update on merging this PR?

[nickithewatt]

@phinze Just checking to see if there's anything specific stopping this from being merged in as we really need it as a feature :) Thanks!

[phinze]

Hey @nickithewatt and @wjam - sorry for the silence on this! I've returned to this thread several times over the past few weeks and 💭 but not typed anything. I'll share my thoughts now in the hopes that we can resolve this one way or another.

My hesitation stems from the fact that this works around ignore_changes bugs, which are being squashed on a semi-regular basis. I wanted to circle back around and test the scenario this solves w/ an ignore_changes solution again, since I have a hunch it will work properly now.

I have also hesitated merging this PR as-is because the name feels odd to me, and I can't come up with a better one. I tend to treat "difficult to name well" as a cause for further thinking.

If either of you have a chance before I do to exercise an ignore_changes based demo and you still run into trouble, I'm willing to continue to pursue this as a stop gap.

Again, sorry for the delay - definitely want to get this workflow sorted out for you in the near future! 👍

[nickithewatt]

@phinze will do a check with latest terraform (0.7.3) and current ignore_changes functionality and see if it's fixed. If not will let you know!

[nickithewatt]

@phinze @wjam I have tested the ignore_changes with the latest terraform (0.7.3) and it seems like this particular case has indeed been addressed and now works as expected :)

[phinze]

Thanks @nickithewatt! This tracks with my tests as well. As such I think we can drop the need for an additional field here. Going to close for now. Anybody on this thread can feel free to chime in if you disagree!

[ghost]

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.