`Depends_on` in Terraform Providers

`Depends_on` in Terraform Providers(discuss.hashicorp.com)

2 points by yarosh 3 years ago | 5 comments

yarosh 3 years ago |

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.

verdverm 3 years ago | |

https://dagger.io

yarosh 3 years ago | | |

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