Hacker News Reader

Comment by jacques_chester | Hacker News Reader

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.

View on HN

> "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.

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.

Always, always view (and save to disk) tf's plan. And if it looks good, apply the saved plan output.

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.

Do you keep a state file per environment or do you have one big state file for all your environments?

I would consider this a bug - if you can open an issue on the https://github.com/hashicorp/terraform repository, we will look into it prior to 0.7.1.

> 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.

Reply on news.ycombinator.com