Terraform should have remained stateless • Hacker News Board

Re: Terraform should have remained stateless

#241

Post by enobrev » Sat, May 28, 2022, 2:35 PM UTC

stingraycharles wrote: post #149

pharmakom wrote: post #98

The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…

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?

That's still storing state, except instead of keeping it within a single file which you have full control over, you're instead sprinkling that state all over your infrastructure and then hoping it doesn't get mangled in between invocations.

And also hoping that service's API has all the tools needed to find your scattered state within a reasonable amount of time in order to diff any changes you make in your declarations

Re: Terraform should have remained stateless

#242

Post by bobobob420 » Sat, May 28, 2022, 2:35 PM UTC

Terraform is amazing and better than its competitors because of its statefulness

Re: Terraform should have remained stateless

#243

Post by sly010 » Sat, May 28, 2022, 2:55 PM UTC

Re: handling unmanaged resources, you have 2 options:

1. Everything not declared is unmanaged. Deleting is done by a "deleted" attribute of some sort. The resource is declared as deleted.

2. Everything unmanaged is declared as unmanaged. The resource is declared as unmanaged and TF would ignore it.

Either of those would work without extra state.

Re: Terraform should have remained stateless

#244

Post by NateEag » Sat, May 28, 2022, 3:09 PM UTC

ntoskrnl wrote: post #195

NateEag wrote: post #190

Earlier quoted context omitted.

That's what TXT records are for: https://en.m.wikipedia.org/wiki/TXT_record

Terraform can be used to manage TXT records too. Where does it store metadata for them? Or is it TXT all the way down?

You can have multiple TXT records for a given domain name, so it would be possible to store an arbitrary amount of metadata for whatever systems you desire, and just loop through the TXT records to figure out which ones are for the current system's purpose.

Re: Terraform should have remained stateless

#245

Post by NateEag » Sat, May 28, 2022, 3:12 PM UTC

gtirloni wrote: post #193

NateEag wrote: post #190

Earlier quoted context omitted.

That's what TXT records are for: https://en.m.wikipedia.org/wiki/TXT_record

Exposed to the world?

I guess that's not ideal, though I'm not clear what attack surface area is increased by storing creation/ deletion metadata in public.

I guess it lets an attacker know that you're using Terraform, which might help them target their attacks.

Re: Terraform should have remained stateless

#246

Post by ratww » Sat, May 28, 2022, 3:17 PM UTC

aayjaychan wrote: post #28

rwiggins wrote: post #22

Earlier quoted context omitted.

Presumably you'd encode removed resources somehow in the DSL. Maybe a flag like `removed = true`.

I'll consider this a variation on moving state elsewhere. Now you have to keep the deleted resource forever. Or keep track of which environments the version with the removal directive is deployed to, or risk having orphaned resources in different environments.

> Now you have to keep the deleted resource forever

Not really. In every other system you can remove tombstones after a while.

Re: Terraform should have remained stateless

#247

Post by runlevel1 » Sat, May 28, 2022, 3:19 PM UTC

pharmakom wrote: post #98

The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…

In Chef, you have to change the resource to `action :remove` if you want it deleted.

Couldn't you do something like that?

Re: Terraform should have remained stateless

#248

Post by candiddevmike » Sat, May 28, 2022, 3:22 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.

You can manage cloud resources using puppet and Ansible...

Re: Terraform should have remained stateless

#249

Post by bpicolo » Sat, May 28, 2022, 3:25 PM UTC

NateEag wrote: post #245

gtirloni wrote: post #193

Earlier quoted context omitted.

Exposed to the world?

I guess that's not ideal, though I'm not clear what attack surface area is increased by storing creation/ deletion metadata in public. I guess it lets an attacker know that you're using Terraform, which might help them target their attacks.

Terraform stores secrets in state. Generated database password, etc.

Re: Terraform should have remained stateless

#250

Post by andrelaszlo » Sat, May 28, 2022, 3:28 PM UTC

Simple counterexample from this week. I added a Heroku app webhook to Terraform. They have some flags, and an ID. Without storing the state, there would be no way, using only the Heroku API, to know which webhook is supposed to be managed by Terraform.

I don't understand where the 99% comes from. Maybe I'm just using the wrong services, but it seems more like 50% to me, anecdotally. Maybe 90% if you include hacks like storing "tags" in other fields like the description or resource name.

If it's truly 99% for you, it seems like it wouldn't be too hard to make a tool that generates an ephemeral TF state file from the services on the fly. Win-win? Or you'd run into the next problem, collecting all the state all the time would probably be really slow in big projects.