2 ms·

Terraform is pretty good; but its strength is its weakness; the declarative syntax (DAG planner) isn't perfect and once you start hinting it, it causes all sort

Terraform is pretty good; but its strength is its weakness; the declarative syntax (DAG planner) isn't perfect and once you start hinting it, it causes all sort of chaos. The solution to complex deploys that re-use portions of the deployments you would want to put a context boundary on, is a series of modules that maintain their own state. But this forces you to pass large amounts of the same data (couples the modules strongly to the main file) over and over again. As for collaborative, terragrunt works pretty good ;) provided you can give a home to the statefile. The real problem I have with terraform/aws (or insert provider) is that its still time-intensive to actually do the deploys. The parallelization of the terraform graph, is "simple" at best. If anyone wants to collaborate on a fork of packer/terraform, let me know on thread.

marenkay 8y ago
Wouldn't the fact that passing resource to modules works in 0.12 help with the mass exodus of output variables for modules? What is time-intensive in terms of deploys? It has been my experience with tens of providers that the time loss occurs when the requests have been handed off to a providers API but not so much in Terraform. As for Terraform itself, my biggest issue is that it has turned around the view of resources and providers. It should have been going in the direction of https://github.com/google/go-cloud https://github.com/google/go-cloud where you talk in terms of resources, and then a provider loaded would just provide the implementation. Now I have to build Terraform modules to export resource and hide away provider specifics in the module.
- paulgrant999 8y ago
  > Wouldn't the fact that passing resource to modules works in 0.12 help with the mass exodus of output variables for modules? might. I skipped it, use soft-links, and hard outputs (variable files) to get around it. cuts down on the graph, I can set explicit boundaries (on whats getting eval'd) without having to go through the terraform DSL. equivalent to running separate terraform scripts, on separate portions of the infrastructure. data source providers (understandably) are not static; there is no way to cache the output of data providers between runs; which means any query retriggers dependencies eval which rebuilds perfectly fine infrastructure. hence why I just output static files. Now there is no chance for terraform to think this variable might change, and ergo, no chance for rebuild of infrastructure that doesn't need it. > It has been my experience with tens of providers that the time loss occurs when the requests have been handed off to a providers API but not so much in Terraform. Agree. So this is sort of the point. I don't need to actually bring up machines in a typical DAG fashion - so some of the work is parallelizable. But other parts aren't. If I need 20 machines, I know I need 20 machines. If the AMI's are loaded on the cloud provider, there is absolutely no reason to have them loaded sequentially (such as a "post-config" might require) i.e. incurring large wait times. Once you start using "terraform" variables (off of resources), that is what you get. So I prefer a different variable resolution mechanism (i.e. lazy/evented). Particularly now that you can ghetto-leverage the cloud providers tag systems, in order to do "proto" service discovery (tag machines for eventual service discovery/config i.e. similar to ansible roles). I'm twisting the hell out of terraform (for things it is not intended to do). but that is because I want to avoid adding yet another tool to the toolchain. More declarative DSL's = more issues to diagnose. > As for Terraform itself, my biggest issue is that it has turned around the view of resources and providers. not so much a problem for me (not multi-cloud). I like knowing (at a glance) what provider-specific features I can expect to be supported. The problem with trying to abstract out cloud provider, is you go with the lowest common denominator (in terms of declarative syntax). > It should have been going in the direction of https://github.com/google/go-cloud https://github.com/google/go-cloud Never used it. Also I've never written a terraform module. So its entirely plausible, this is where my issues would be resolved (custom provider) and an "enhanced" dsl.

marenkay 8y ago

Wouldn't the fact that passing resource to modules works in 0.12 help with the mass exodus of output variables for modules? What is time-intensive in terms of deploys? It has been my experience with tens of providers that the time loss occurs when the requests have been handed off to a providers API but not so much in Terraform. As for Terraform itself, my biggest issue is that it has turned around the view of resources and providers. It should have been going in the direction of https://github.com/google/go-cloud https://github.com/google/go-cloud where you talk in terms of resources, and then a provider loaded would just provide the implementation. Now I have to build Terraform modules to export resource and hide away provider specifics in the module.

paulgrant999 8y ago
> Wouldn't the fact that passing resource to modules works in 0.12 help with the mass exodus of output variables for modules? might. I skipped it, use soft-links, and hard outputs (variable files) to get around it. cuts down on the graph, I can set explicit boundaries (on whats getting eval'd) without having to go through the terraform DSL. equivalent to running separate terraform scripts, on separate portions of the infrastructure. data source providers (understandably) are not static; there is no way to cache the output of data providers between runs; which means any query retriggers dependencies eval which rebuilds perfectly fine infrastructure. hence why I just output static files. Now there is no chance for terraform to think this variable might change, and ergo, no chance for rebuild of infrastructure that doesn't need it. > It has been my experience with tens of providers that the time loss occurs when the requests have been handed off to a providers API but not so much in Terraform. Agree. So this is sort of the point. I don't need to actually bring up machines in a typical DAG fashion - so some of the work is parallelizable. But other parts aren't. If I need 20 machines, I know I need 20 machines. If the AMI's are loaded on the cloud provider, there is absolutely no reason to have them loaded sequentially (such as a "post-config" might require) i.e. incurring large wait times. Once you start using "terraform" variables (off of resources), that is what you get. So I prefer a different variable resolution mechanism (i.e. lazy/evented). Particularly now that you can ghetto-leverage the cloud providers tag systems, in order to do "proto" service discovery (tag machines for eventual service discovery/config i.e. similar to ansible roles). I'm twisting the hell out of terraform (for things it is not intended to do). but that is because I want to avoid adding yet another tool to the toolchain. More declarative DSL's = more issues to diagnose. > As for Terraform itself, my biggest issue is that it has turned around the view of resources and providers. not so much a problem for me (not multi-cloud). I like knowing (at a glance) what provider-specific features I can expect to be supported. The problem with trying to abstract out cloud provider, is you go with the lowest common denominator (in terms of declarative syntax). > It should have been going in the direction of https://github.com/google/go-cloud https://github.com/google/go-cloud Never used it. Also I've never written a terraform module. So its entirely plausible, this is where my issues would be resolved (custom provider) and an "enhanced" dsl.