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

31–40 of 329 posts

Re: Terraform should have remained stateless

#31

Post by NovemberWhiskey »

throwaway892238 wrote: post #29

Having a state file isn't a bad idea. State files are a logical map from your code to the AWS resources. You can actually import a resource that Terraform never created into a state file so that Terraform can manage it. But of course, you could just write the code to explicitly include that pre-existing resource, rather than have to run a command to tell a state file to explicitly include it. The problem with Terrafo…

You might think that's useful behavior; personally I absolutely prefer the Terraform model of having to explicitly import things into state that weren't created by Terraform.

Re: Terraform should have remained stateless

#32

Post by c3534l »

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…

If its not specified to be there, it shouldn't be there.

Re: Terraform should have remained stateless

#33

Post by NovemberWhiskey »

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…

That seems like madness to me: YAML? Really? Is this some variant of K8s Stockholm syndrome?

It's always seemed to me that one of the virtues of Terraform was that the language was just declarative, and rich enough to express what you needed without becoming a Turing tarpit.

Re: Terraform should have remained stateless

#34

Post by shepherdjerred »

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 most familiar with AWS, but I assume Azure and GCP have similar features.

Use some tag unique to the project and tag all resources on creation. When deleting resources delete everything not in your stack that has the tag. You can find these resources using the provider's tagging APIs, e.g. https://aws.amazon.com/blogs/aws/new-aws-resource-tagging-ap...

Re: Terraform should have remained stateless

#35

Post by throwaway892238 »

NovemberWhiskey wrote: post #31
throwaway892238 wrote: post #29

Having a state file isn't a bad idea. State files are a logical map from your code to the AWS resources. You can actually import a resource that Terraform never created into a state file so that Terraform can manage it. But of course, you could just write the code to explicitly include that pre-existing resource, rather than have to run a command to tell a state file to explicitly include it. The problem with Terrafo…

You might think that's useful behavior; personally I absolutely prefer the Terraform model of having to explicitly import things into state that weren't created by Terraform.

Because you get paid more per hour?

Re: Terraform should have remained stateless

#36

Post by nathants »

amen! as another commenter here rightly put:

state or idempotency, pick one.

hello? how is this even a question? i have a hard time believing that idempotent infrastructure mutations are not the right move almost always.

shameless plug[1], i’ve been exploring an aws specific approach to infrastructure that is stateless and idempotent for exactly these reason.

slow, finicky, stateful deploys are about as awful as it gets. add a pinch of lowest common denominator among all providers, and that’s a tough pill to swallow.

there’s got to be another way, aws should be fun!

1. https://github.com/nathants/libaws

Re: Terraform should have remained stateless

#37

Post by tuckerman »

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…

This isn’t about terraform, but in other systems I’ve had to put in tombstones to explicitly turn down a service. This allowed for services to exist that weren’t managed by that partition of state while still allowing for the automation to handle turndowns.

Re: Terraform should have remained stateless

#38

Post by NovemberWhiskey »

c3534l wrote: post #32
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…

If its not specified to be there, it shouldn't be there.

That sounds logical, but it's not very practical due to the cost of enumeration; plus, it requires providers to gain deep knowledge into things that are implied dependencies ... like "hrmmm, should I try to delete this service-linked role or do I actually need it?"

Re: Terraform should have remained stateless

#39

Post by NovemberWhiskey »

throwaway892238 wrote: post #35
NovemberWhiskey wrote: post #31

Earlier quoted context omitted.

You might think that's useful behavior; personally I absolutely prefer the Terraform model of having to explicitly import things into state that weren't created by Terraform.

Because you get paid more per hour?

Why so snarky? No; because if the goal is repeatable infrastructure, I don't want the bits that are non-repeatable to be silently assumed - you just end up with a cloud-centric version of "it works on my machine".
Post reply on HN