Hacker News Reader

Comment by danielvaughn | Hacker News Reader

In my (very limited) experience with Terraform, the pain isn't so much associated with state, but rather with the declarative nature of the code.

I feel like imperative Terraform would be easier to reason about, since it matches up with the non-terraform workflow (i.e. go here add this, then go here and configure that, yadda yadda).

When I read HCL, I really struggle in understanding the order of priorities. Like I know that surely some things must be built first, and supposedly it's all handled under the hood. But I'd rather be in control tbh.

Then again, as I said, I don't have much experience with Terraform so maybe I'm way off?

View on HN

Apart from very specific scenarios where you really know you need explicit order, it's not something I ever think about. You've got two options really:

1. One resource depends on another through the attributes, like an autoascaling group depending on a subnet. This is handled automatically by Terraform - updates/ordering will happen in the right way.

2. Dependencies that exist outside of configuration. For example some domain name should be created before some service starts. You can add those explicitly through `depends_on` for the resource that needs it.

Going imperative would lose most of what's interesting about Terraform. Imagine you create a service then change some attributes. Now you want another environment that looks the same - how would you do that imperatively? Replay all changes from scratch? Flatten the history and create a new script? With declarative Terraform what you're running is already in your configuration, no changes needed.

In the best case this is true. In the worst case the behavior of a resource in state X differs depending on it having been in state Y, so you have the same problem.

But that's not related to the tool anymore. You'll have the same issue regardless how you created that resource. Also, FWIW, I've been dealing with automation of services through Terraform and others for 2 decades or so and never ran into an issue like that. The one that comes closest is AWS certificate which requires either a parallel deployment or the first attempt to fail (if you're using cloudformation stacks anyway). Still - not a serious issue in practice.

Glad to know you’ve been dealing with Terraform for longer than the 8th highest contributor. Lots of AWS resources behave this way. Perhaps you’re not doing anything serious enough to run into these conditions?

I wrote "through Terraform and others", not Terraform only.

Instead of trying to gotcha me, do you want to provide some examples where creating a resource and changing an attribute results in something different than creating one with the final attribute values?

EKS clusters is a good one. A cluster starting at Kubernetes 1.28 will be in a wildly different state to one upgraded from Kubernetes 1.17 and upgraded through every version. More has come under management scope since 1.17, but even today the add-on model doesn’t cover lots of important aspects.

S3 buckets are another - it’s no longer even possible to create some types of buckets that exist in the wild today, thanks to changes in how canned ACLs may be provisioned. Older buckets have their access rules unchanged however.

These are two super common resources in the biggest cloud. I’m sure if I went digging in Azure or GCP I could find dozens of non-trivial cases of this that actually make a difference - database-as-a-service offers are likely a target-rich environment for this.

That's a different issue than what I thought you're talking about, and I'm not sure why it's relevant here. None of the declarative/imperative systems can deal with future compatibility. The service you're using may change the meaning of some API call/values - there's nothing we can do about it apart from updating the software, whether you're using Terraform or Ansible.

> Then again, as I said, I don't have much experience with Terraform so maybe I'm way off?

Yes. HCL is the easiest part of terraform.

State management / knowing what a particular tf apply is going to do and if it will put your stuff in an irreversible state where you have to go in and manually fix it is the hardest part. For us, we are forever struggling with IAM policies and KMS key aliases, especially if there is also a developer boundary coming into play as well.

Reply on news.ycombinator.com