Terraform should have remained stateless • Hacker News Board

Re: Terraform should have remained stateless

#221

Post by taeric » Sat, May 28, 2022, 1:30 PM UTC

nathants wrote: post #70

taeric wrote: post #45

Earlier quoted context omitted.

Sorta. Creation is only easy if you know what the expected state is. Did you just create a new table, or was it already created? This is especially hard when you /want/ table names that are not stable.

using names to uniquely identify infrastructure is very convenient and how most of aws already works. why not take advantage of that instead mapping name to uuid via state? in what scenario are non-stable infrastructure names useful?

If you are using cloud formation, it already does a uuid like name on resources it creates.

Re: Terraform should have remained stateless

#222

Post by pharmakom » Sat, May 28, 2022, 1:31 PM UTC

usrn wrote: post #212

kkdaemas wrote: post #191

Earlier quoted context omitted.

No because the metadata on the deleted resource is now lost. With the information being stored outside the resource, we know that it was deleted and the metadata about it.

That's not state information though, that's metadata.

If some state information is stored using metadata then we need that metadata to know the total state. The contents of TF state is more than what can be read from the provider APIs often.

Re: Terraform should have remained stateless

#223

Post by chrisweekly » Sat, May 28, 2022, 1:33 PM UTC

tomgouder wrote: post #159

stingraycharles wrote: post #149

Earlier quoted context omitted.

The whole idea of the article is that “previous state” is something that can be derived from tags / metadata in the provider’s resources, rather than a standalone file. In other words, this metadata then is the state. Could you give an example of a situation / transition that cannot be captured correctly by managing the state using these types of tags?

I agree that state can be removed in Terraform. But I do not believe leveraging tags and/or metadata is the right approach - configuration for these resources could potentially be large (e.g. GKE resources) and most providers will have a size constraint on their metadata and tag values. Creating a metadata/tag key for each configuration key would also get messy, but solves the value size problem. Why wouldn’t it be p…

"should be able to rely on the provider’s APIs to understand what exists" is the crux of it. Provider APIs, in praxis, are insufficient / impractical.

Re: Terraform should have remained stateless

#224

Post by boesboes » Sat, May 28, 2022, 1:53 PM UTC

scapecast wrote: post #125

psanford wrote: post #82

Earlier quoted context omitted.

There are a lot of resources in AWS that don't support tags.

Do you have a few examples?

Unfortunatly, it's just enough to be a problem in many cases:

Route53 records, ECR repositories, Cloudwatch Alarms, IAM user groups, EC2 Launch configuration

Re: Terraform should have remained stateless

#225

Post by jen20 » Sat, May 28, 2022, 1:55 PM UTC

GauntletWizard wrote: post #16

janosdebugs wrote: post #11

I respectfully disagree. If TF was stateless, you'd have to manage situations by hand that involve changing the idempotency key, such as the name of a VM. You'd also have to manage situations by hand where a resource is removed from the config. The whole point of TF is that it has state and doesn't require workarounds for these scenarios. Yes, you have to maintain state, but the state problems usually come from buggy…

Terraform already has to manage those, and yet worse - Changes to the name of objects within the state were entirely manual until 1.0. Changes to objects underneath terraform often break the connection. Terraform doesn't have good tooling built in to find orphan resources, which it would if it were working with stateless objects. Terraform would be much better without state. Not 10x better, but 2x.

This is absolutely untrue: changes to the logical name were manual until 0.6, CLI driven until recently, and encoded in config as of more recently. Changes to physical resource names is a per-provider concern and is supported wherever the upstream allows it.

Orphan resources only exist as a concept if you manage entire estates in a single configurations, which is simplistic to the extreme.

If I use local_file to emit a certificate authority for an EKS cluster, does that mean every other file on my file system is suddenly orphaned? What if the networking team responsible for VPCs, routing and transit search for orphaned resources in my AWS account - should that include all my instances?

If you think Terraform would be better without state, I’d encourage you to put your money where your mouth is and build it.

Re: Terraform should have remained stateless

#226

Post by sgt » Sat, May 28, 2022, 1:55 PM UTC

Jasp3r wrote: post #165

m1keil wrote: post #51

> Ansible, Puppet, etc. don’t have intermediate stores of the hosts’ configuration, but then again they are used for different things. Ansible, Chef, Puppet and co existed long before Terraform. If the stateless way would work better, these tools take over the cloud infrastructure space. But they didn't. To me it seems like a good sign that the their approaches didn't fit to infra. Additionally, one of the biggest te…

Ansible and Puppet are for infrastructure automation across multiple VMs. Terraform is a way to declare cloud (native) infrastructure as code. Ansible and Puppet are not used anymore because of the shift to cloud native, not because they are stateless.

We adopted Ansible two years ago. Still using it. So clearly there are some users.

Re: Terraform should have remained stateless

#227

Post by w3456yhbvr5yh » Sat, May 28, 2022, 1:57 PM UTC

smcleod wrote: post #187

w3456yhbvr5yh wrote: post #180

Earlier quoted context omitted.

"time sink" is also how i would describe CF templates and wrappers like SAM. I'd be grateful if you could elaborate on the CDK issues. I'm also curious to know how many people in this thread consider themselves developers as opposed to devops/cloud engineers.

There is so much toil involved in the software framework(s) around CDK, the most common CDK language is typescript - which while in many ways is better than JavaScript still suffers from the same garbage ecosystem. The serious problem with CDK is that it's just a wrapper for CloudFormation - so you have all the limitations of a CFn backend with the added complexity of a full general programming language and ecosystem…

Thanks for the detailed response.

Re: Terraform should have remained stateless

#228

Post by jen20 » Sat, May 28, 2022, 2:02 PM UTC

raffraffraff wrote: post #143

rbongers wrote: post #127

Earlier quoted context omitted.

Are you saying it should? I think whether that's desirable or not is a matter of preference. The nice thing about Terraform is that you don't have to go all in. I don't really want to have to tell it to ignore every resource that I want to manually manage, and I don't want it wasting the extra API calls on trying to find every resource that's not in my configuration every time I want to deploy. Now, if they provided…

Not suggesting it "should", I was just pointing out that it's not a complete drift detection tool.

That was a deliberate choice made. Terraform development has a cardinal rule: do not touch objects you did not create.

It could do drift detection for existence rather easily if that was relaxed, but the rule follows the principle of least surprise.

Re: Terraform should have remained stateless

#229

Post by jen20 » Sat, May 28, 2022, 2:04 PM UTC

smcleod wrote: post #46

gkop wrote: post #2

Thank you OP for answering a question I’ve been long curious about but never bothered to look into, and sharing here. I love/hate Terraform. It’s better than any other tool I’ve used for what it does, but the abundance of subtly leaky abstractions is tedious. And then when you mess up your state occasionally, yea that’s super annoying too.

After spending the last 6 months with AWS CDK - I'd kill to go back to using Terraform which is far from perfect but light years ahead of CDK which is the most consuming time sink I've ever had to work on, it's truly dreadful. Give me Terraform any day!

“Broken time sink” is more inherent to CloudFormation than CDK per se - if you want to write code instead of config Pulumi is likely a better choice.

Re: Terraform should have remained stateless

#230

Post by jen20 » Sat, May 28, 2022, 2:08 PM UTC

GeneralMayhem wrote: post #77

pst wrote: post #72

Earlier quoted context omitted.

The delete this approach is imperative though. If you aim to be declarative you need a way for the tool to be able to determine actions necessary to go from current to new desired configuration. You need to store previous applied config somewhere, to be able to determine if something needs purging in a declarative way.

You don't need to store the full old configuration anywhere other than as part of the current configuration. All you need is a list of IDs that existed in previous configurations. Something like: current_tables { TableA { Column1[string] Column2[bool] } } removed_tables: ["TableOld", "AnotherOldTable", ...] Depending on your ergonomic preferences, you could also accomplish that by keeping the old table configs and ad…

That is a state file by any other name. Terraform could work this way with fairly trivial code changes, and the cost of blowing up provider rate limits during fast incremental development (the kind of places where you set -refresh=false).