Fix permanent diff on aws_opsworks ssh_key and password

[xsalazar]

Summary

Previously, there was an issue when using custom_cookbooks_source in the aws_opsworks_stack resource, Terraform would continuously reapply changes to both ssh_key and password despite no changes actually happening.

This is because, on read, the resourceAwsOpsworksSetStackCustomCookbooksSource method would create an intermediate map before attempting to update the resource data. However, map entries for both Password and SshKey were removed, since the AWS API will return *****FILTERED***** for sensitive data.

Since these entries were removed, they would be read as empty strings, and when Terraform compared these read values to the values in code, there would always be a difference between the code and empty string. Thus, every terraform apply would claim a difference and rewrite those values.

To solve this issue, the old value from the resource data is copied into the intermediate map and Terraform will no longer think it detects changes to these properties where there are none.

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

Related Issues

#165
#176
#421
#4411
hashicorp/terraform#6203
hashicorp/terraform#6648
hashicorp/terraform#3635
hashicorp/terraform#6192
hashicorp/terraform#6826
hashicorp/terraform#10675
hashicorp/terraform#4790
hashicorp/terraform#17959

Release Notes

Release note for CHANGELOG:

- Fixes issue where `terraform apply` continuously suggests applying changes to `ssh_key` or `password` in `custom_cookbooks_source` property for `aws_opsworks_stack`
- Fixes issue where `terraform apply` continuously suggests applying changes to `ssh_key` or `password` in `app_source` property for `aws_opsworks_application`

Test

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccAWSOpsworksStack_CustomCookbooks_SetPrivateProperties' TEST=./aws
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test ./aws -v -parallel 20 -run=TestAccAWSOpsworksStack_CustomCookbooks_SetPrivateProperties -timeout 120m
=== RUN   TestAccAWSOpsworksStack_CustomCookbooks_SetPrivateProperties
=== PAUSE TestAccAWSOpsworksStack_CustomCookbooks_SetPrivateProperties
=== CONT  TestAccAWSOpsworksStack_CustomCookbooks_SetPrivateProperties
--- PASS: TestAccAWSOpsworksStack_CustomCookbooks_SetPrivateProperties (58.38s)
PASS
ok  	github.com/terraform-providers/terraform-provider-aws/aws	58.655s

[xsalazar]

Paging @apparentlymart since he started this work in #176. Would you be able to review this?

[wagner]

@xsalazar is this the same issue affecting aws_opsworks_application.app_source.ssh_key?

[xsalazar]

@wagner Yeah, it looks like there's an issue in there as well. It's the same mapping pattern, but the existing code for getting the password is wrong, and the missing ssh_key suffers from the same issue that this PR solves.

You can also double check the AWS API and see that the password will never be returned!

[xsalazar]

Would @apparentlymart or @bflad be able to check out this PR? It would close quite a few tickets and is pretty straightforward.

[aeschright]

Looks good! We just need a documentation update, similar to https://www.terraform.io/docs/providers/aws/r/emr_cluster.html#kerberos_attributes-1

[xsalazar]

@aeschright done!

[aeschright]

Thanks for this patch! 🌟

--- PASS: TestAccAWSOpsworksStack_CustomCookbooks_SetPrivateProperties (35.92s)

[ghost]

This has been released in version 2.39.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 for triage. Thanks!

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!