For certain API groups there are resources that belong to them, which have references in both directions: If, for example, we have API groups a and b, it could be the case that there are resources in a referring to resources in b, and there are resources in b referring to resources in group a. This results in the prohibited import cycles in the generated code when we manually configure the reference fields.
How could Terrajet help solve your problem?
For certain cases, it would help to be able to override the Terraform-implied generated API group of a resource with something similar to:
, which will generate the VirtualNetwork resource as github.com/crossplane-contrib/provider-tf-azure/apis/networking/v1alpha1.VirtualNetwork instead of the default github.com/crossplane-contrib/provider-tf-azure/apis/virtual/v1alpha1.VirtualNetwork.
What problem are you facing?
For certain API groups there are resources that belong to them, which have references in both directions: If, for example, we have API groups
a
andb
, it could be the case that there are resources ina
referring to resources inb
, and there are resources inb
referring to resources in groupa
. This results in the prohibited import cycles in the generated code when we manually configure the reference fields.How could Terrajet help solve your problem?
For certain cases, it would help to be able to override the Terraform-implied generated API group of a resource with something similar to:
, which will generate the
VirtualNetwork
resource asgithub.com/crossplane-contrib/provider-tf-azure/apis/networking/v1alpha1.VirtualNetwork
instead of the defaultgithub.com/crossplane-contrib/provider-tf-azure/apis/virtual/v1alpha1.VirtualNetwork
.