4 ms·

The state management system always struck me as very flawed design, and it's the reason I've not yet used Terraform. After all, it means that you have to start

The state management system always struck me as very flawed design, and it's the reason I've not yet used Terraform. After all, it means that you have to start from scratch. If you any existing infrastructure — instances, load balancers, DNS, whatever — then anything you declare in Terraform will conflict, even if it's declared exactly identically. A workaround is to manually reverse-engineer your current state into a state file, or use a third-party tool like Terraforming [1], but it still breaks the second anyone (either accidentally or intentionally for whatever reasons) bypasses Terraform and touches the world directly, so Terraform simply isn't resilient by design. Surely one of the primary uses of a tool like this must be that if something is modified behind your back, you are secure in the knowledge that you can whip out Terraform and it will force the world back into the right shape in a few seconds? That being said, 0.7 has an import command now, so they recognize the problem. It's extremely limited and is not a complete solution yet, however. I never understood the purpose of the state file. A tool like Terraform, from my perspective, should be stateless. It ought to compare its target to the world, and then attempt to converge the world to match the target. You could have local state as an option, in particular to detect interference, but I don't see why it's needed at all times. My current solution is to use Salt (not Salt Cloud, just the Salt "boto" states, using local masterless mode), but it's pretty terrible. I would really want a tool like Terraform, but without the flawed state management. [1] https://github.com/dtan4/terraforming https://github.com/dtan4/terraforming

jen20 10y ago
> After all, it means that you have to start from scratch. If you any existing infrastructure — instances, load balancers, DNS, whatever — then anything you declare in Terraform will conflict, even if it's declared exactly identically. One of the major features of the version released today is the ability to import existing resources in to Terraform state.
- lobster_johnson 10y ago
  I wrote about that. That being said, 0.7 has an import command now, so they recognize the problem. It's extremely limited and is not a complete solution yet, however.
mitchellh 10y ago
The state management is a primary focus for us right now, and I think that's evident from this release: state management CLI tools as well as the beginning of import (which is primarily dealing with state in this iteration). > ... it still breaks the second anyone ... bypasses Terraform and touches the world directly, so Terraform simply isn't resilient by design. This shouldn't be true. If you create a new resource that was never under management by Terraform, then yes, Terraform will ignore it. This is by design so that you can use Terraform to manage infrastructure and use other processes to manage other infrastructure that perhaps isn't quite migrated yet OR doesn't fit Terraform's model for whatever reason. However, if you change a resource under management or even remove it, Terraform will notice this. It is very resilient to detecting drift. > I never understood the purpose of the state file. The purpose is to map your resources to what exists in the world. There must be some way to make a mapping there to be able to do diffing, drift detection, etc. Some cloud platforms provide interesting ways to work around this (AWS tags are often abused for this) and we actually experimented with that approach early on. Unfortunately, not everything supports tags and there was no way for us to separate what was Terraform managed and what wasn't. One of the features we actually have planned for Terraform in the future is the ability for it to tell you what IS NOT under Terraform management (by comparing local state to global state). For companies that have everything under management, this will be a great check to find any rogue resources. For companies working on adopting Terraform, this will help find things that still need to be migrated/imported. So, hopefully our state improvements in 0.7 and in the short term will help sway you. They're definitely a top concern. But I also hope I explained my way through some of the design here! Thanks for the feedback and we hope to see you in the community soon!
- jacques_chester 10y ago
  I think that opening changes in state via a CLI is a fast path to making things worse.[0] I greatly prefer the BOSH model: "give me a manifest and I will make the world look like it". Documents are easily versionable. Commands aren't. Documents narrow scope and can be more easily made idempotent as an automatic guarantee. Commands require us to remember to check the state ourselves, manually, before doing something. That said, Terraform has a significantly different low-level model. BOSH looks at the size of the problem and imposes non-negotiable primitives to scope that complexity. Terraform is more ambitious. I suspect Terraform will be easier to adopt incrementally, but harder to manage on a per-unit-of-state basis. [0] Loosely related: http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/ http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...
jacques_chester 10y ago
> A tool like Terraform, from my perspective, should be stateless. It ought to compare its target to the world, and then attempt to converge the world to match the target. This is how BOSH has been doing it for years for IaaS setup and other systems like Salt/Puppet/Chef/cfengine for servers. Compare-and-repair is a fairly well-accepted, trustworthy model. Disclaimer: I work for Pivotal, we donate most of the engineering on BOSH. [0] https://bosh.io/ https://bosh.io/
- nikolay 10y ago
  CloudFormation is stateless as well.

jen20 10y ago

> After all, it means that you have to start from scratch. If you any existing infrastructure — instances, load balancers, DNS, whatever — then anything you declare in Terraform will conflict, even if it's declared exactly identically. One of the major features of the version released today is the ability to import existing resources in to Terraform state.

lobster_johnson 10y ago
I wrote about that. That being said, 0.7 has an import command now, so they recognize the problem. It's extremely limited and is not a complete solution yet, however.

mitchellh 10y ago

The state management is a primary focus for us right now, and I think that's evident from this release: state management CLI tools as well as the beginning of import (which is primarily dealing with state in this iteration). > ... it still breaks the second anyone ... bypasses Terraform and touches the world directly, so Terraform simply isn't resilient by design. This shouldn't be true. If you create a new resource that was never under management by Terraform, then yes, Terraform will ignore it. This is by design so that you can use Terraform to manage infrastructure and use other processes to manage other infrastructure that perhaps isn't quite migrated yet OR doesn't fit Terraform's model for whatever reason. However, if you change a resource under management or even remove it, Terraform will notice this. It is very resilient to detecting drift. > I never understood the purpose of the state file. The purpose is to map your resources to what exists in the world. There must be some way to make a mapping there to be able to do diffing, drift detection, etc. Some cloud platforms provide interesting ways to work around this (AWS tags are often abused for this) and we actually experimented with that approach early on. Unfortunately, not everything supports tags and there was no way for us to separate what was Terraform managed and what wasn't. One of the features we actually have planned for Terraform in the future is the ability for it to tell you what IS NOT under Terraform management (by comparing local state to global state). For companies that have everything under management, this will be a great check to find any rogue resources. For companies working on adopting Terraform, this will help find things that still need to be migrated/imported. So, hopefully our state improvements in 0.7 and in the short term will help sway you. They're definitely a top concern. But I also hope I explained my way through some of the design here! Thanks for the feedback and we hope to see you in the community soon!

jacques_chester 10y ago
I think that opening changes in state via a CLI is a fast path to making things worse.[0] I greatly prefer the BOSH model: "give me a manifest and I will make the world look like it". Documents are easily versionable. Commands aren't. Documents narrow scope and can be more easily made idempotent as an automatic guarantee. Commands require us to remember to check the state ourselves, manually, before doing something. That said, Terraform has a significantly different low-level model. BOSH looks at the size of the problem and imposes non-negotiable primitives to scope that complexity. Terraform is more ambitious. I suspect Terraform will be easier to adopt incrementally, but harder to manage on a per-unit-of-state basis. [0] Loosely related: http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/ http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...

jacques_chester 10y ago

> A tool like Terraform, from my perspective, should be stateless. It ought to compare its target to the world, and then attempt to converge the world to match the target. This is how BOSH has been doing it for years for IaaS setup and other systems like Salt/Puppet/Chef/cfengine for servers. Compare-and-repair is a fairly well-accepted, trustworthy model. Disclaimer: I work for Pivotal, we donate most of the engineering on BOSH. [0] https://bosh.io/ https://bosh.io/

nikolay 10y ago
CloudFormation is stateless as well.