`Depends_on` in Terraform Providers | Hacker News Reader

`Depends_on` in Terraform Providers

discuss.hashicorp.com

2 pointsyarosh5 comments

Really tired of overcoming the existing design limitations of terraform.

I think that this is a global issue that had been neglected for far too long, and too many people had been struggling with this due to pointless hashicorp excuses, of "being understaffed" or "this goes against the design of a single consolidated plan".

I think that Consolidated Infrastructure State and Consolidated State Locks are far more important than the Consolidated Plan itself.

Consolidated plan is simply impossible for multi-stage deployments and can be omitted during the First Infrastructure Deployment.

Having multiple deferred plan refresh phases, alongside the dependency calculation is something that should be tolerable. We're tolerating the "known after compute" type of situation for everything else anyway.

https://dagger.io

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

Have you looked at crossplane?

https://github.com/crossplane/crossplane

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.

Reply on news.ycombinator.com