Add use_previous_values field to aws_cloudformation_stack

[marcinwyszynski]

By explicitly asking Terraform to use previous values for CloudFormation templates, we can prevent situations where upon changing the template code Terraform would wipe out external changes made to the CF stack. This is subtly different from Terraform's semantics of ignoring changes, so requires a separate and more delicate approach.

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

Closes #307

Release note for CHANGELOG:

Added `use_previous_values` field to `aws_cloudformation_stack` to explicitly tell CloudFormation to not change parameter values on stack update.

[marcinwyszynski]

My sincere apologies for the lack of tests, but what's going on in here is kinda invisible to Terraform and only makes sense to CloudFormation. I suppose one could unit-test the bit of reconciling parameters with use_previous_values and check if the resulting input.Parameters is consistent with what's expected. On the other hand, this style of testing isn't what you're guys doing in the repo.

If there's anything I can help with regards to testing this change, please kindly give me a hint how you'd like to go about it.

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

[Vishal-Shunyeka]

Any Updates on this PR?