[yarosh]

Yes, a lot can be automated with CUE and it would work similarly to tfcdk, which could potentially solve a lot of multistage deployment issues by manually managing multiple dependent terraform states.

Having unified terraform state on the other hand would help with static analysis and dependency tracking.

There are also fairly interesting Operator Designs, where Kudo like operators could be replaced with the respective terraform modules in terms of consul-terraform-sync.

My struggle for unified terraform state is mostly based on this operator-replacement design possibility. It would be more flexible than Kudo and could help resolving postmortem support cases.

For instance, AWS Support tends to refuse support EKS postmortem cases when any operators had been installed to that EKS cluster... So, having no operators whatsoever has it's own "political benefit".

https://www.terraform.io/cdktf https://kudo.dev/ https://github.com/hashicorp/consul-terraform-sync

[verdverm]

Have you looked at crossplane?

https://github.com/crossplane/crossplane

[yarosh]

Yes, of course.

I don't really like neither crossplane nor pulumi due to the lack of providers. And to my personal opinion they would've better spent some resources to contribute to the target providers instead of embedding or directly code-generating (https://github.com/crossplane/terrajet) from Terraform. Spreading the efforts and resources doesn't really help that much with the existing Terraform issues.

So, I find both pulumi and crossplane rather parasitic for the existing Terraform Provider Infrastructure. Actually fixing the bicycle would've been better than strapping a jet engine on top.

For me, this situation is very similar to the long resolved issue with docker multistage... with myriads of CLI tools on top obsoleting in result.