3 ms·

> "give me a manifest and I will make the world look like it" This is how Terraform works if you want a one-time setup. You can just throw the state away after

> "give me a manifest and I will make the world look like it" This is how Terraform works if you want a one-time setup. You can just throw the state away after that if you want. But Terraform is supposed to be used (and is very very often used) to do ongoing minimal changes to infrastructure, often dozens of times per day. In this scenario, Terraform's configurations are completely declarative: it is a state of the world you want to reach, it isn't what to do next. However, we require the state file in order to find the resources we own and then refresh the state of the world so we can do a diff.

scrollaway 10y ago
This is a bug we just hit 5 minutes ago on 0.6: One of our CD builds failed because of a configuration issue - a variable wasn't properly set, leading terraform to continuously ask jenkins' stdin for a password. We fixed the bug. But somehow, that previous build wiped the state file. When we pushed the fix, terraform freaked out and started deleting all our instances, including S3 redirects that weren't managed by it which we explicitly told it to ignore. That sucked.
- irq 10y ago
  Always, always view (and save to disk) tf's plan. And if it looks good, apply the saved plan output.
  - scrollaway 10y ago
    Did view it... locally. It kind of defeats the point if it's not reliable enough to trust it'll behave the same from a different machine. No harm done, we're still in beta to catch bugs exactly like those, but our initial enthusiasm with terraform has been waning very quickly. Like I said, I love the design, but it's just not there yet.
- hedwall 10y ago
  Do you keep a state file per environment or do you have one big state file for all your environments?
- jen20 10y ago
  I would consider this a bug - if you can open an issue on the https://github.com/hashicorp/terraform https://github.com/hashicorp/terraform repository, we will look into it prior to 0.7.1.
jacques_chester 10y ago
> But Terraform is supposed to be used (and is very very often used) to do ongoing minimal changes to infrastructure, often dozens of times per day. I've seen BOSH used this way. You just have to accept that editing a file and checking it into version control is a good thing. After a while, infrastructure tends to stabilise into a predictable format for the given distributed system under management. I think Terraform would definitely be easier for a fast-developing system because of its bias towards interactivity. But in the long run most systems cease to be fast-developing. At Pivotal we're seeing more and more customers going all-in on BOSH. Not just for Cloud Foundry, but for pretty much every stateful service they can lay a hand on. They like that it's based entirely on versionable, auditable files. > However, we require the state file in order to find the resources we own and then refresh the state of the world so we can do a diff. BOSH will inspect the world when you ask it to, or you can ask it to do so continuously. As a rule, most operators prefer (like Terraform users) to do it manually.

scrollaway 10y ago

This is a bug we just hit 5 minutes ago on 0.6: One of our CD builds failed because of a configuration issue - a variable wasn't properly set, leading terraform to continuously ask jenkins' stdin for a password. We fixed the bug. But somehow, that previous build wiped the state file. When we pushed the fix, terraform freaked out and started deleting all our instances, including S3 redirects that weren't managed by it which we explicitly told it to ignore. That sucked.

irq 10y ago
Always, always view (and save to disk) tf's plan. And if it looks good, apply the saved plan output.
- scrollaway 10y ago
  Did view it... locally. It kind of defeats the point if it's not reliable enough to trust it'll behave the same from a different machine. No harm done, we're still in beta to catch bugs exactly like those, but our initial enthusiasm with terraform has been waning very quickly. Like I said, I love the design, but it's just not there yet.
hedwall 10y ago
Do you keep a state file per environment or do you have one big state file for all your environments?
jen20 10y ago
I would consider this a bug - if you can open an issue on the https://github.com/hashicorp/terraform https://github.com/hashicorp/terraform repository, we will look into it prior to 0.7.1.

jacques_chester 10y ago

> But Terraform is supposed to be used (and is very very often used) to do ongoing minimal changes to infrastructure, often dozens of times per day. I've seen BOSH used this way. You just have to accept that editing a file and checking it into version control is a good thing. After a while, infrastructure tends to stabilise into a predictable format for the given distributed system under management. I think Terraform would definitely be easier for a fast-developing system because of its bias towards interactivity. But in the long run most systems cease to be fast-developing. At Pivotal we're seeing more and more customers going all-in on BOSH. Not just for Cloud Foundry, but for pretty much every stateful service they can lay a hand on. They like that it's based entirely on versionable, auditable files. > However, we require the state file in order to find the resources we own and then refresh the state of the world so we can do a diff. BOSH will inspect the world when you ask it to, or you can ask it to do so continuously. As a rule, most operators prefer (like Terraform users) to do it manually.