When generating new versions of the CRD APIs associated with a managed resource, upjet's code generation pipeline can potentially run into the following issue:
We are generating a (new) API version v1beta2 for resource B
There exists another resource A in the same group as B, whose API is generated at v1beta1
These resources share some common parameters (configuration arguments) with identical canonical paths
upjet's code generation pipeline can normally resolve such conflicts while generating the Go struct names however it relies on a static pipeline that assumes all the types available are being generated. In our case, v1beta1 version of the B resource API is not generated and hence upjet is not aware of it. This results in name conflicts for the generated types.
We have a roadmap item to modularize the code generation pipeline to make it more dynamic and scalable but it's a much larger effort. As a workaround, we had introduced the config.Resource.OverrideFieldNames API through which one can override the name upjet is generating for a CRD type. However, this requires manual configuration.
For most cases, this has been feasible as we rarely do bulk breaking changes in the MR APIs. However recently, we are rolling out API changes across the official providers that replace the singleton lists in the MR APIs with embedded objects (please see https://github.com/crossplane/upjet/pull/387 and https://github.com/crossplane-contrib/provider-upjet-gcp/pull/508 for more context). Such systemic changes affecting multiple resources can result in a need to override the generated type names for many resources. What's worse, @sergenyalcin identified in https://github.com/crossplane-contrib/provider-upjet-azure/pull/733 that the current config.Resource.OverrideFieldNames API is unable to handle certain types of overrides where we need to override the same leaf at multiple paths. We need to be able to specify the canonical paths of the overrides being defined.
So, we've decided to address this issue by making upjet's code generation pipelines aware of the existing previous versions of the CRDs (MR APIs). One can configure an older version of an API as follows:
While generating the CRDs in a package, upjet will then load the type definitions from these previous versions specified and use them as input to its already existing name conflict resolution function.
We also deprecate the config.Resource.OverrideFieldNames API whose only known use case is preventing the type name conflicts in the generated CRDs. So, config.Resource.OverrideFieldNames is deprecated in favor of the `config.Resource.PreviousVersions-based mechanism described above.
Description of your changes
When generating new versions of the CRD APIs associated with a managed resource, upjet's code generation pipeline can potentially run into the following issue:
v1beta2for resourceBAin the same group asB, whose API is generated atv1beta1v1beta1version of theBresource API is not generated and hence upjet is not aware of it. This results in name conflicts for the generated types.We have a roadmap item to modularize the code generation pipeline to make it more dynamic and scalable but it's a much larger effort. As a workaround, we had introduced the
config.Resource.OverrideFieldNamesAPI through which one can override the name upjet is generating for a CRD type. However, this requires manual configuration.For most cases, this has been feasible as we rarely do bulk breaking changes in the MR APIs. However recently, we are rolling out API changes across the official providers that replace the singleton lists in the MR APIs with embedded objects (please see https://github.com/crossplane/upjet/pull/387 and https://github.com/crossplane-contrib/provider-upjet-gcp/pull/508 for more context). Such systemic changes affecting multiple resources can result in a need to override the generated type names for many resources. What's worse, @sergenyalcin identified in https://github.com/crossplane-contrib/provider-upjet-azure/pull/733 that the current
config.Resource.OverrideFieldNamesAPI is unable to handle certain types of overrides where we need to override the same leaf at multiple paths. We need to be able to specify the canonical paths of the overrides being defined.So, we've decided to address this issue by making upjet's code generation pipelines aware of the existing previous versions of the CRDs (MR APIs). One can configure an older version of an API as follows:
While generating the CRDs in a package, upjet will then load the type definitions from these previous versions specified and use them as input to its already existing name conflict resolution function.
We also deprecate the
config.Resource.OverrideFieldNamesAPI whose only known use case is preventing the type name conflicts in the generated CRDs. So,config.Resource.OverrideFieldNamesis deprecated in favor of the`config.Resource.PreviousVersions-based mechanism described above.I have:
make reviewableto ensure this PR is ready for review.backport release-x.ylabels to auto-backport this PR if necessary.How has this code been tested
Tested in the context of https://github.com/crossplane-contrib/provider-upjet-azure/pull/733 & https://github.com/crossplane-contrib/provider-upjet-gcp/pull/508. As an example, please observe the changes in here, where the API is replaced and we observe no diff in the generated APIs.