Open dikhan opened 4 years ago
Hi Terraform team,
Any updates on this? I am not really sure how to handle this use case and would appreciate some guidance.
Thanks! Dani
Sorry for the delay in responding here. :(
However, as per 21217 comment it was suggested that future versions of the SDK would support complex objects natively without having to use the workaround of TypeList with 1 Elem and I'd really appreciate if you could shed some light on it.
This is accurate. terraform-plugin-go, for example, can use objects natively. This functionality hasn't made its way to the SDK just yet, but we're working on it.
I was wondering if the expectation/recommendation is still to configure complex objects using TypeList with Elem *Resource and limit size of 1?
It depends, but generally, yes.
P.S: I was hoping this could be supported as part of the major upgrade to SDK 2.0.0 considering it would potentially involve introducing breaking changes and seemed like a good opportunity to do it.
Me, too. :( Unfortunately, even though we were going to be making some breaking changes, we needed to temper the number of breaking changes we made to make the upgrade palatable and achievable for busy provider developers. While we technically could break all the existing provider code, doing so is really expensive and places a huge barrier to adoption. So we had to pick and choose carefully what we broke and what we left, even if it meant leaving some things in states we weren't totally happy with.
Sadly, supporting maps of resources is not as straightforward a request as it seems. It involves untangling a lot of code that has been around for six years, that hundreds of providers have written thousands of resources against. As we learned with Terraform 0.12, providers sometimes rely on implementation details of that code, and so it's really risky for us to change it. Adding support for Resources as map values is a really large undertaking, because it means picking through and modifying all that code, and then making sure it's not going to have some really unfortunate unintended consequences.
We have a way out of this mapped out, but we're a small team and a lot of people have direct dependencies on the code we're writing, so we're trying to be careful and it just takes time. I know that's frustrating--I'm frustrated by it, too :( -- but we're moving in the right direction. Hopefully terraform-plugin-go is an indicator of that.
Context
I am in the process of upgrading the OpenAPI Terraform provider to use the new Terraform SDK 2.0, and some int tests are now throwing the following error:
TypeMap with Elem*Resource not supported
Previous versions of the SDK allowed TypeMap to have an associated Elem schema.Resource; however the behaviour was unpredictable causing diff issues etc. The main goal was to have an object type definition that contained different properties types (eg: string, int, etc) and configurations (eg: mix of props where some are expected as input from the user and others are are computed aka readOnly). As per other issues raised in the past 21217 and 22511, this seemed not to be supported and the recommendation from Terraform maintainers back then was to configure the property instead as TypeList with Elem Resource and limit size of 1. However, as per 21217 comment it was suggested that future versions of the SDK would support complex objects natively without having to use the workaround of TypeList with 1 Elem and I'd really appreciate if you could shed some light on it.
After updating to v2.0.3, looks like Terraform no longer supports TypeMap with Elem schema.Resource (as per debug output section) so I was wondering if the expectation/recommendation is still to configure complex objects using TypeList with Elem Resource and limit size of 1?
SDK version
Relevant provider source code
The OpenAPI Terraform provider automatically converts the following
ContentDeliveryNetworkV1
definition into its corresponding Terraform schema.Schema as shown below (pasting the yaml too for the ref). Option 2 works as expected; Option 1 now fails due to SDK 2.0 no longer supporting TypeMap with Elem *Resource.Terraform Configuration Files
Debug Output
Expected Behavior
TypeMap with Elem Resource is supported so objects that objects containing props with different types (eg: string, int, etc) or configurations (eg: mix of props where some are expected as input from the user and others are are computed aka readOnly) can be defined in the terraform schema without having to use the workaround of configuring the property as TypeList with Elem Resource and limit size of 1
P.S: I was hoping this could be supported as part of the major upgrade to SDK 2.0.0 considering it would potentially involve introducing breaking changes and seemed like a good opportunity to do it.
Actual Behavior
TypeMap with Elem *Resource not supported
Steps to Reproduce
Please list the full steps required to reproduce the issue, for example:
terraform init
terraform apply
References