Terraform should have remained stateless • Hacker News Board

Re: Terraform should have remained stateless

#91

Post by dkdbejwi383 » Sat, May 28, 2022, 6:39 AM UTC

GeneralMayhem wrote: post #58

NovemberWhiskey wrote: post #14

Uh, how do you delete resources with this model? If you don't have any state, and you have an empty module, did you just create it, or did you just remove all the resources from it? The former requires no action, the latter requires API calls to delete something that I no longer have a record of. More generally, do I have to completely enumerate the entire state of every service available to my AWS account to determi…

I'm in the process of building a tool that's basically Terraform, but for database schemas - you define the tables and columns in something like a proto or JSON, and it will do exactly what this article describes: read the current state of the world, plan out a minimal series of updates (avoiding destructive updates, and keeping dependencies in mind for things like foreign keys), and then apply them. The solutions fo…

Sounds similar to “Migra” for Postgres.

Re: Terraform should have remained stateless

#92

Post by nathants » Sat, May 28, 2022, 6:40 AM UTC

loxias wrote: post #3

Completely agree. Thanks for writing this up. Specifically because I've always thought this, but also don't value my opinion on the topic. I was first exposed to devops a few years ago, and as a result was learning docker, k8s, terraform, salt, &c. at the same time. (I hated it, and now I'm happy writing C++ again) What I could never wrap my head around was why the heck the tools had to expose so much complexity. I w…

this is the ideal approach for most scenarios. fewer knobs, simpler tooling.

Re: Terraform should have remained stateless

#93

Post by jvitor03 » Sat, May 28, 2022, 6:42 AM 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…

Looks like you are creating based on puppet or ansible, not Terraform :)

The whole idea of TF is to not have to declare an absent resource for it to be destroyed, because the declarative approach already have the desired state.

Re: Terraform should have remained stateless

#94

Post by moondev » Sat, May 28, 2022, 6:45 AM UTC

nailer wrote: post #88

NovemberWhiskey wrote: post #14

Uh, how do you delete resources with this model? If you don't have any state, and you have an empty module, did you just create it, or did you just remove all the resources from it? The former requires no action, the latter requires API calls to delete something that I no longer have a record of. More generally, do I have to completely enumerate the entire state of every service available to my AWS account to determi…

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.

Re: Terraform should have remained stateless

#95

Post by jvitor03 » Sat, May 28, 2022, 6:53 AM UTC

GeneralMayhem wrote: post #58

NovemberWhiskey wrote: post #14

Uh, how do you delete resources with this model? If you don't have any state, and you have an empty module, did you just create it, or did you just remove all the resources from it? The former requires no action, the latter requires API calls to delete something that I no longer have a record of. More generally, do I have to completely enumerate the entire state of every service available to my AWS account to determi…

I'm in the process of building a tool that's basically Terraform, but for database schemas - you define the tables and columns in something like a proto or JSON, and it will do exactly what this article describes: read the current state of the world, plan out a minimal series of updates (avoiding destructive updates, and keeping dependencies in mind for things like foreign keys), and then apply them. The solutions fo…

> Once you've fully adopted, then you can flip a flag to "I own the whole world" mode, where the default is to delete anything not found in the canonical configuration.

That may work for a database, but for a cloud provider for example(which i dare to say, its the main usage), it's unlikely to work, because of the amount of requests needed to check all possible resources and ids or tags. Also those applies usually happens multiple times in a day issued by different users/ci automations, so there's not enough api quota to cover them all and each plan would take forever to finish depending on your organization size.

Re: Terraform should have remained stateless

#96

Post by inferiorhuman » Sat, May 28, 2022, 6:56 AM UTC

outsomnia wrote: post #73

m1keil wrote: post #66

Earlier quoted context omitted.

In what way? All these tools are "DSLs to API calls with idempotency guards" engines. This is exactly what a stateless TF would be. They all been extended with DSLs that allowed them to manage resources in AWS and other cloud providers. These are in use but far cry away from popularity of tools such as Terraform, Cloudformation and others.

From the article: Ansible, Puppet, etc. don’t have intermediate stores of the hosts’ configuration, but then again they are used for different things.

Last I checked Ansible can cache facts to a persistent store like a file.

Re: Terraform should have remained stateless

#97

Post by zlumer » Sat, May 28, 2022, 6:58 AM UTC

GeneralMayhem wrote: post #58

NovemberWhiskey wrote: post #14

Uh, how do you delete resources with this model? If you don't have any state, and you have an empty module, did you just create it, or did you just remove all the resources from it? The former requires no action, the latter requires API calls to delete something that I no longer have a record of. More generally, do I have to completely enumerate the entire state of every service available to my AWS account to determi…

I'm in the process of building a tool that's basically Terraform, but for database schemas - you define the tables and columns in something like a proto or JSON, and it will do exactly what this article describes: read the current state of the world, plan out a minimal series of updates (avoiding destructive updates, and keeping dependencies in mind for things like foreign keys), and then apply them. The solutions fo…

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 TypeScript typings for the DB client.

Re: Terraform should have remained stateless

#98

Post by pharmakom » Sat, May 28, 2022, 7:03 AM UTC

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 managed by Terraform

If everything were managed by Terraform then perhaps we would not need state, but this is not realistic in my view.

Re: Terraform should have remained stateless

#99

Post by InvertedRhodium » Sat, May 28, 2022, 7:07 AM UTC

inferiorhuman wrote: post #96

outsomnia wrote: post #73

Earlier quoted context omitted.

From the article: Ansible, Puppet, etc. don’t have intermediate stores of the hosts’ configuration, but then again they are used for different things.

Last I checked Ansible can cache facts to a persistent store like a file.

Puppet also has PuppetDB, which is functionally similar.

Re: Terraform should have remained stateless

#100

Post by 8organicbits » Sat, May 28, 2022, 7:07 AM UTC

I haven't found a good way to handle resources that were created outside TF. Like a EC2 instance running in staging to debug an issue, but then forgotten about. They don't exist in TF state or config so TF simply ignores them.

I've tried terraformer[1], but I can't tell how well maintained that is (it failed to get my creds, I had to modify the code to fix it, and then it crashed with an obscure error).

Anyone have a good approach?

1. https://github.com/GoogleCloudPlatform/terraformer