Reapply changes to avoid destroying instance on user_data updates

[rogerhu]

Community Note

Reapplying changes from #16011 to address #23

This change will update user_data/user_data_base64 and reboot the instance instead of destroying the instance.

The code that deals with shutting down the instance and updating the attributes is consolidated into one function.

Relates to #16011 and #7863
Closes #23

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccAWSInstance_userDataChange'

TF_ACC=1 go test ./aws -v -count 1 -parallel 20 -run=TestAccAWSInstance_userDataChange -timeout 120m
=== RUN   TestAccAWSInstance_userDataChange
=== PAUSE TestAccAWSInstance_userDataChange
=== CONT  TestAccAWSInstance_userDataChange
--- PASS: TestAccAWSInstance_userDataChange (234.00s)
PASS
ok  	github.com/terraform-providers/terraform-provider-aws/aws	235.562s

[rogerhu]

Can someone take a look?

[rogerhu]

Checking in again :)

[rogerhu]

Ping again. :). Anyone home?

[rogerhu]

@anGie44 @bflad @YakDriver if you have a chance

[korenlev]

please take a look at this PR , waiting long time for this

[nsvijay04b1]

Hello..

when can we expect this ? thanks!

[GoodMirek]

@bflad @YakDriver @hashicorp-cloud Any chance to review this enhacement?
The related issue and its predecessor have been opened for over 6 years, since 2015. Justification for this enhacement is e.g. in this comment.

[ricardo-aspira]

Hello @ewbankkit,
Isn't it a good feature that we could release for the community?
I have seen a couple of use cases with our customers.

Thanks for your time.

[zhelding]

Pull request #21306 has significantly refactored the AWS Provider codebase. As a result, most PRs opened prior to the refactor now have merge conflicts that must be resolved before proceeding.

Specifically, PR #21306 relocated the code for all AWS resources and data sources from a single aws directory to a large number of separate directories in internal/service, each corresponding to a particular AWS service. This separation of code has also allowed for us to simplify the names of underlying functions -- while still avoiding namespace collisions.

We recognize that many pull requests have been open for some time without yet being addressed by our maintainers. Therefore, we want to make it clear that resolving these conflicts in no way affects the prioritization of a particular pull request. Once a pull request has been prioritized for review, the necessary changes will be made by a maintainer -- either directly or in collaboration with the pull request author.

For a more complete description of this refactor, including examples of how old filepaths and function names correspond to their new counterparts: please refer to issue #20000.

For a quick guide on how to amend your pull request to resolve the merge conflicts resulting from this refactor and bring it in line with our new code patterns: please refer to our Service Package Refactor Pull Request Guide.

[anGie44]

Hi @rogerhu, thank you for your contribution and continuing the work in #7863. I'll be reviewing this PR and before getting started i'll rebase this if the Allow Maintainer Edits checkbox is checked.

[anGie44]

unfortunately we'll need to update attributes individually as the API will return an error such as

InvalidParameterCombination: Fields for multiple attribute types specified: instanceType,userData

[anGie44]

Output of acceptance tests:

--- PASS: TestAccEC2Instance_userDataBase64 (103.52s)
--- PASS: TestAccEC2Instance_userDataBase64_update (287.10s)

--- PASS: TestAccEC2Instance_UserData (103.57s)
--- PASS: TestAccEC2Instance_UserData_emptyStringToUnspecified (129.45s)
--- PASS: TestAccEC2Instance_UserData_unspecifiedToEmptyString (139.80s)
--- PASS: TestAccEC2Instance_UserData_update (186.83s)

--- PASS: TestAccEC2Instance_changeInstanceType (338.25s)
--- PASS: TestAccEC2Instance_changeInstanceTypeAndUserData (267.82s)
--- PASS: TestAccEC2Instance_changeInstanceTypeAndUserDataBase64 (244.71s)

[anGie44]

Thank you again @rogerhu , LGTM 🚀

[github-actions]

This functionality has been released in v4.2.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[danorchard82]

Is there a way to opt-out of this behavior change? I (as I'm sure many) have been relying on instances being destroyed/created when the user data changes, to result in an instance with the given user data executed. This is a breaking change to me.

[v4de]

This is causing tons of problems in our CI/CD pipelines where changes in user data are NOT forcing a replacement. This change should be only for people that do NOT have idempotent infrastructure and should be a FLAG. @anGie44 @rogerhu

This issue has been opened and the workaround is to use an older version of this provider. #23315

[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.