While having two different providers for the same API is doable, the UX is usually not great if you decide to use both because of reason. It'd be great if we have a single complete one.
How could Terrajet help solve your problem?
TF-based providers could reach full feature parity and in that case, Terraform would really be an implementation detail. So, we can consider merging for example provider-tf-aws into provider-aws, covering only the missing resources so that we can generate CRR references between manual written, ACK generated and TF generated. And we'd have one provider to point to.
One drawback is that the API changes once we'd like to move underlying resource implementation from TF to ACK or manual and vice versa.
Though we can discuss this only after alpha version.
muvaf
commented
2 years ago
What problem are you facing?
While having two different providers for the same API is doable, the UX is usually not great if you decide to use both because of reason. It'd be great if we have a single complete one.
How could Terrajet help solve your problem?
TF-based providers could reach full feature parity and in that case, Terraform would really be an implementation detail. So, we can consider merging for example provider-tf-aws into provider-aws, covering only the missing resources so that we can generate CRR references between manual written, ACK generated and TF generated. And we'd have one provider to point to.
One drawback is that the API changes once we'd like to move underlying resource implementation from TF to ACK or manual and vice versa.
Though we can discuss this only after alpha version.