Identifier fields in spec.initProvider

[mbbush]

What problem are you facing?

As a maintainer of crossplane-contrib/provider-upjet-aws, I often find myself wishing to improve the external name configuration of an existing resource, in cases where the terraform id can be built from the parameters, but the provider is currently using the IdentifierFromProvider external name config. This provides usability improvements by allowing a managed resource to assume control of an existing matching external resource, rather than generating an error unless the user explicitly specifies the external-name annotation in the correct but undocumented format for that particular resource kind.

Generally, this results in some of the fields becoming identifier fields, which is appropriate, because they are part of the identifier of the resource. However, as a consequence, they are removed from spec.initProvider, which is a breaking schema change.

How could Upjet help solve your problem?

I can think of three possible solutions, any one of which would make these sorts of external name config improvements easier.

1. Include identifier fields in spec.initProvider, and use some sort of merging logic to read from both initProvider and forProvider when constructing the external name/terraform id.
2. Remove all the RequiresNew fields from initProvider as proposed in Remove immutable fields from initProvider #384, since almost all fields which form part of a terraform resource id are immutable.
3. Make identifier fields optional in both initProvider and forProvider, and allow upjet to construct the terraform id from the external name (if specified), or from the identifier fields (if the external name annotation is not specified)? I might like this idea best if paired with the "promotion" of the external-name from an annotation to a field like spec.externalName, so that we could write validation rules for the identifier fields that require sufficient information to construct the external name if it is not specified.