Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terraform should have remained stateless

bejarano.io

Post reply on HN
Print view View original

111–120 of 329 posts

Re: Terraform should have remained stateless

#111

Post by pharmakom »

moondev wrote: post #94
nailer wrote: post #88

Earlier quoted context omitted.

Make it so that TF deletes anything not in your config unless whitelisted next question.

What about the opposite which is how kubectl works. "terraform delete" only deletes what is in your config. "terraform apply" only creates and/or updates what is in your config. If you remove a resource from your config after applying it, it's your responsibility to manually delete it.

Not having to manually delete is one of the reasons I use Terraform. Managing state is much less painful than that would be.

Re: Terraform should have remained stateless

#112

Post by chucky_z »

cmclaughlin wrote: post #44
chucky_z wrote: post #5

You can use terraform in a "stateless" manner! Define everything in like cdk (... I use ruby to generate the tf.json), generate the code, import everything you can without error, and apply the rest. Performance will be _bad_ but that will completely eliminate state problems.

cdktf doesn’t really help with state problems in my opinion. Under the hood terraform is still storing state and if you’re working on a team you’ll need to share state, e.g to s3. If you don’t have any state and try to make a change, terraform will try to recreate and fail. Importing is a pain. cdktf is great, but I would also rather do away with the state. I’ve gotten into too many problems that were only resolved b…

Oh I mean using the synth stage to write ephemeral code to disk to be applied against “to be imported state.” Disclaimer: this is a terrible idea if you aren’t using state.

I use this today to keep very “wide” modules synced

Re: Terraform should have remained stateless

#113

Post by pharmakom »

cmeacham98 wrote: post #64
aayjaychan wrote: post #21

If Terraform is stateless, how does it know what it needs to / can delete? You'll either have to: - Move the state management elsewhere, and invoke different commands depends on what and how resources are changed. This will make automation difficult, and doesn't solve the problem. - Make Terraform assume that everything it sees is under its management, deleting everything not defined in the current configuration. Thi…

Most (all?) cloud providers support some form of tagging. Have like a `managed-by=terraform` tag, and assume everything with that tag is Terraform managed.

Not all of them have tags.

Re: Terraform should have remained stateless

#115

Post by zlumer »

pharmakom wrote: post #108
zlumer wrote: post #97

Earlier quoted context omitted.

We're doing something similar using Prisma. We have a script that queries Postgres database periodically and generates a Prisma schema for the tables/columns. Then the script diffs previous schema with a newer one and if any changes are detected, it creates an SQL migration and commits it to the git repo. That way we have a history of all changes in a very readable way, and an always up-to-date Prisma schema and Type…

Uhhh shouldn’t that be the other way around? You should write the migrations and commit them to Git THEN apply them to the database after review?

If you describe the workflow for the production DB, then yes, that's exacly how it works.

But we also need a way to fiddle with the dev environment, while keeping track of everything that happened during development phase and making sure that it can be applied to the production DB in a single command with little room for errors.

Having a git repo in sync with the DB and a full history of changes in commit log helps a lot.

Re: Terraform should have remained stateless

#116

Post by cheradenine_uk »

janosdebugs wrote: post #107
GauntletWizard wrote: post #16

Earlier quoted context omitted.

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.

I think there is a misunderstanding: when I'm talking about "name" I mean the "name" stored by the cloud provider, which is typically (arbitrarily) chosen as the idempotency key by stateless implementations. When you change the name of the resource that will, obviously, break the connection, that's a big no-no when writing Terraform code.

Sure, but isn't the artcle suggesting tags rather than the name / ID ?

One problem, as mentioned in a sibling comment, is if you don't have state then how do you know a resource has been deleted? One other option might be a system that compares the "desired state" from the previous version of the config. That might be an interesting approach - keeping a history of config. But that is, of course, state :)

I use TF a bit. I want to like it, but I do spend inordinate amounts of time faffing around with state files to make them match reality, and I'm not even doing particularly complex stuff. I'm told other tooling (eg: Bicep for Azure) dispenses with state entirely.

Re: Terraform should have remained stateless

#117

Post by raffraffraff »

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…

I'll play devil's advocate (because I understand the need for a state):

What if terraform was able to perform a complete audit of your environment for each provider and say "this is what you've got, mate", then give you options for each resource:

1. Accept (turns it into terraform code)

2. Reject (removes the resource)

Taken further, this idea effectively means that manually creating something like EKS could be a way to auto-compose Terraform code and store it in git.

Pros:

* You have the options of writing code, using the console or using a script or binary to perform a complex setup

* You have 100% code coverage once Terraform compared code with reality and forced you to choose

Cons:

* Auto-generated code is shitty.

* Slooooooow without caching (which is only one of the functions of state)

To make these concepts work without a remote state you pretty much have to run your infrastructure tool as a service, and implement things like:

1. Polling of providers on an interval

2. Alerting when something changes

3. Eventually consistent cache that can be forcibly updated in the UI or during sensitive operations

4. "Infrastructure Composer" UI, like a vastly simplified IaaS console that only shows deployed infrastructure and lets you group infrastructure by service, and let you define code-level modules

5. Show discovered dependencies and ordering, and allow you to explicitly set them (these should be stored as tags on the actual infrastructure components where possible)

6. Use some hot AI to group code-level resources, compare their configurations and generate config data to apply to resources/modules using for_each loops, while respecting service boundaries and offering advice on when to refactor.

Re: Terraform should have remained stateless

#118

Post by rbongers »

Is "remained stateless" accurate? The document only indicates that they used to try storing state in tags, not that it was stateless. "Stateless", to me, would mean that it tries to compare current resources with your current configuration without any metadata.

If you mean that they should have tried to keep using tags, not every resource and cloud provider supporting tags pretty much ends the possibility of that.

If you mean they should have gone completely stateless, I would say that state is great for detecting configuration drift. If Terraform tries to create a new resource, is it being created for the first time, or was it manually removed? You can only tell with state. Sure, you can get this information in a number of other ways, but one of the major strengths of Terraform is as an easy drift detection tool.

I get the desire for state not to exist, but in reality it is essential for what Terraform does.

Re: Terraform should have remained stateless

#119

Post by rbongers »

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.

I don't quite follow - why would it be able to find orphaned resources if it were working with stateless objects?
Post reply on HN