Open lukehoban opened 5 years ago
Looking at this again with @iwahbe and team -
We might be identifying this as a breaking change in schema-tools already as of today, but we do not attribute it to MaxItemsOne in the output schema-tools produces.
Current approach is to automate withholding MaxItems=1 changes until next major release and then taking a break.
Supporting smooth migrations for every language like (2) seems a tad difficult especially for languages like Go. Java say could handle Union[T, List[T]] via overloads and be backwards compatible. But no sure how to do this in Go.
https://github.com/pulumi/pulumi-terraform-bridge/issues/1667 is a pre-requisite here.
Today, all
MaxItems:1
properties are projected as scalars instead of arrays. This is fine, but if the TF schema ever changes to remove this limitation (because the underlying resource beings accepting multiple items), then this will result in a breaking change in Pulumi that is not a breaking change in Terraform.We could possibly handle this without a breaking change by:
For (2), this would likely involve allowing two different input properties on the Pulumi side to map to the same Terraform schema input, and making these two mutually exclusive from Pulumi. Then also exposing two output properties, one the scalar which gets automatically populated from
[0]
on the underlying resource, and the other the whole array from the underlying resource.