search

crossplane / terrajet

Generate Crossplane Providers from any Terraform Provider
https://crossplane.io
Apache License 2.0
290 stars 38 forks source link

Keep custom resource configuration separated from generated sources #91

Closed ulucinar closed 2 years ago

ulucinar commented 2 years ago

What problem are you facing?

We currently import apis package of the Terrajet-based provider with a blank identifier to get the resource configuration registrations to be done with a map. This makes it difficult to wipe out generated resources and in case there are compile errors in the generated source files which are about to be regenerated, we cannot run the generator pipeline.

How could Terrajet help solve your problem?

We had better keep the generated sources separate from the developed ones, and do not use init functions for registering resource configurations.

muvaf commented 2 years ago

Some more context here. Even if we delete only the generated files via find apis -iname 'zz_*.go' | xargs rm -rf && find internal -iname 'zz_*.go' | xargs rm -rf we get no Go files errors. Once we fix that, since the CRD packages are not imported anywhere, their init() function in custom.go stop being called, hence the initial generation doesn't have the effect of the configuration.

I don't have a strong opinion about where to put the generated files but I'd prefer us to have explicit call to register the custom configurations instead of using init(), which turned out to be working well with kubebuilder since it doesn't expect package to be error-free but our tooling does. We can have a config.Provider object initialized in cmd/generator/main.go and then write a apis/config.go file manually that will call SetForResource for every custom configuration with config.Provider given from main.go.

muvaf commented 2 years ago

@ulucinar I just remembered that we have https://github.com/crossplane-contrib/terrajet/issues/80 , do you think they are duplicate?

turkenh commented 2 years ago

We've already separated configs from generated files in both of the existing tf providers and as part of #61, I will be working on unifying the way we are doing this. So, closing this issue.