One-element arrays could be considered as objects

[muvaf]

What problem are you facing?

There are cases where a field is actually a struct in the API but Terraform has it as single-element array, like here https://github.com/hashicorp/terraform-provider-aws/blob/7ff39c5b11aafe812e3a4b414aa6d345286b95ec/internal/service/efs/access_point.go#L52

How could Upjet help solve your problem?

We can generate the arrays with maxLength: 1 as structs so that we don't run into much patching problems and also the structural difference between the cloud API and CRD would be reduced. Though this would mean a breaking change, hence new apiVersion for many resources.

I think we should assess how reliable maxLength: 1 condition is to figure out whether it should be struct or not. If it's close to 100%, it may be worth to bear the burden.

[shanproofpoint]

imho, I think the provider should hide the terraform limitations from the idealized API.
having it leak through to the upbound gcp public API defeats abstraction and is the antithesis of crossplane..
perhaps the provider can do some transformation before giving it to terraform.

[mbbush]

If we find cases where the maxLength: 1 condition is not 100% reliable, it would also be nice to have a customization in config for enabling or disabling this, along the lines of config.MoveToStatus.

As much as I am frustrated by the need to have all of these single element arrays, (especially when patching to spec.forProvider.foo[0].bar[0].baz.other[0]), it is nice to be able to have a consistent set of rules that I can apply in my head when reading terraform and translating it to crossplane.