resource/aws_cloudfront_distribution: Get rid of flatmap dependency

[radeksimko]

As part of some preparation work for SDK decoupling I found this provider imports a legacy flatmap package - this isn't the way we plan to represent data in the SDK in the future anymore and it would be awesome if we could reduce the "core surface" exposed to providers by removing this dependency/import.

The CloudFront Distribution resource apparently uses this for "flattening" SDK struct into a map here

https://github.com/terraform-providers/terraform-provider-aws/blob/b13ffce6248b6eadda3cd9ffd1664ac1aafe5f39/aws/cloudfront_distribution_configuration_structure.go#L1100-L1116

the affected field active_trusted_signers is TypeMap
https://github.com/terraform-providers/terraform-provider-aws/blob/b13ffce6248b6eadda3cd9ffd1664ac1aafe5f39/aws/resource_aws_cloudfront_distribution.go#L697-L700

which makes me doubt whether this actually ever worked - there isn't any test to prove it and I don't think we have much successful history of using TypeMap for nested structures.

I suppose the easiest way to resolve this would be migrate the schema to TypeList & MaxItems: 1?

[apparentlymart]

In Terraform 0.12 I would expect Terraform Core to be picky about values for this argument being exactly lists of strings, and so this would be appearing in the rest of the configuration as a map with the keys items.#, items.0.aws_account_number, items.0.key_pair_ids.#, items.0.key_pair_ids.0, etc.

Probably in 0.11 this tricked the interpolator into converting this structure into a list of maps, because it only had the flatmap keys to work from, but the new protocol shims will see that this is a map and will serialize it as one so Terraform 0.12 will not be so easily fooled.

Changing this to be (essentially) list(object({aws_account_number=string, key_pair_ids=list(string)})) would make it behave differently in Terraform 0.12, because the language will then see it as a real nested data structure, rather than as a flat map. It might also require a state migration for anyone who already created their cloudfront distribution with Terraform 0.12 and so has this saved in the new structured storage format.

Leaving it as a map of string using flatmap-style keys -- either by hand-writing some simpler, more specialized code to generate it just for this case, or by copying the flatmap package into the AWS provider -- is probably the best way to keep this compatible for both Terraform 0.11 and 0.12 users.

[bflad]

Pull request submitted: #10013

[bflad]

flatmap usage has been removed. 🎉

[ghost]

This has been released in version 2.28.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!

[bflad]

Reopening as #10013 will be reverted by #10093

[bflad]

For now, this will move the flatmap package internally, so we can still migrate away from using the github.com/hashicorp/terraform dependency: #10244

[anGie44]

Re-introducing the changes originally made in #10013 is now merged with #14339 and will release with the upcoming v3.0.0 of the Terraform AWS Provider

[ghost]

This has been released in version 3.0.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!