Terraform should have remained stateless • Hacker News Board

Re: Terraform should have remained stateless

#201

Post by whydoineedthis » Sat, May 28, 2022, 12:26 PM UTC

m1keil wrote: post #182

Jasp3r wrote: post #165

Earlier quoted context omitted.

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.

I wasn't suggesting that CMS fell from grace because they were being stateless. I was saying that when TF just started, these tools were in the right position to take lead over the IaaC space and didn't because the stateless model didn't fit. Take a look at Ansible's cloud modules, they tried. TF's success, in my opinion, can be boiled down to: a) Having a state - allowed them to provide declarative config with plan…

Off topic, but, cdk-tf is useless because it doesn't have a data layer. It gives you the power to write real code, but with no vars to utilize. It's rubbish.

Re: Terraform should have remained stateless

#202

Post by Aeolun » Sat, May 28, 2022, 12:29 PM UTC

rtp4me wrote: post #173

rwiggins wrote: post #12

Having worked with both Terraform and Ansible code that created AWS resources - and operates very similarly to the model described here [0, see `filters` arg] - I generally disagree. For example, if you changed an ID in your stateless Terraform, you'd have to insert some kind of code to destroy (or rename, if possible) the old resource. Or modify the Terraform DSL to include that kind of information, I suppose, and k…

I am starting on a journey to deploy resources in the big three cloud providers (AWS, Azure, Google) and could use your input. So far, we have been working with Ansible to provision our AWS resources. Because we find Ansible to be a pain to use, we are considering Terraform - especially when working with multiple cloud providers. Do you have any advice or best practices to properly deploy and manage instances using T…

I would suggest maybe bypassing terraform entirely and going to something like Pulumi or CDK.

Re: Terraform should have remained stateless

#203

Post by moondev » Sat, May 28, 2022, 12:30 PM UTC

zeckalpha wrote: post #200

moondev wrote: post #196

Assuming every resource has a name field, auto prefix it with "tf-" If the resource is prefixed with "tf-" but missing in the terraform config, delete it.

What happens when you have multiple terraform repositories interacting with the same account?

another prefix for terraform workspace name, similar to how netflix uses the name field for metadata https://gist.github.com/johnrengelman/12e8d975344c7945ab1127...

Re: Terraform should have remained stateless

#204

Post by noirbot » Sat, May 28, 2022, 12:35 PM UTC

Jasp3r wrote: post #163

EwanToo wrote: post #157

Earlier quoted context omitted.

This is the fundamental misconception of the article as far as I understand it. Cloud providers do not provide enough metadata to enable that mapping across all resources.

That cloud providers provide such muddy/inadequate APIs that it is impossible to view the state they are in is a very bold claim to make. Do you have an example to back this up?

I'm amused that you think "cloud providers have bad APIs" is a bold claim instead of the default state of things. Things as basic as IAM Groups in AWS aren't taggable: https://registry.terraform.io/providers/hashicorp/aws/latest...

IAM Users are taggable, but to get the tags on a given user, you must request them one user at a time from a known list of users. The "List all users" call doesn't return their tags. Obviously this is less of an issue for the TF state use case, but does add to the API call overhead for any tag-based approach.

Re: Terraform should have remained stateless

#205

Post by [deleted] » Sat, May 28, 2022, 12:45 PM UTC

[deleted]

Re: Terraform should have remained stateless

#206

Post by grumple » Sat, May 28, 2022, 12:46 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?

> Could you give an example of a situation / transition that cannot be captured correctly by managing the state using these types of tags?

Tags do not solve the deletion issue. It would require two step deployments, for example by adding delete = true to the config, applying, then removing the resource from the config entirely and applying again. But I don't think that's too bad tbh.

Re: Terraform should have remained stateless

#207

Post by agounaris » Sat, May 28, 2022, 12:48 PM UTC

Terraform could have been stateless if the target provider was stateless as well.

Having said that I don't mind state at all! There is always a storage layer and a schema somewhere storing some kind of information.

Re: Terraform should have remained stateless

#208

Post by moondev » Sat, May 28, 2022, 12:48 PM UTC

ntoskrnl wrote: post #199

moondev wrote: post #196

Assuming every resource has a name field, auto prefix it with "tf-" If the resource is prefixed with "tf-" but missing in the terraform config, delete it.

A perfect solution. We'll just have to move our home page to tf-www.example.com

The simple solution is to have tf launch an EKS cluster with route 53 external-dns, then the ingresses can be defined as k8s resources which tf also manages :D

Re: Terraform should have remained stateless

#209

Post by devit » Sat, May 28, 2022, 12:48 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…

Or, you know, put an UUID in the configuration and tag everything with it so that it knows what it created by just querying the tag (or similarly, using a namespace if supported, or putting the information in the resource name itself if possible).

Re: Terraform should have remained stateless

#210

Post by nanis » Sat, May 28, 2022, 12:51 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?

How does that work when terraforming Artifactory?