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

131–140 of 329 posts

Re: Terraform should have remained stateless

#131

Post by maciekmm »

raffraffraff wrote: post #117
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…

That approach wouldn't work if your infrastructure is spread between multiple Terraform workspaces. (as is often done).

Re: Terraform should have remained stateless

#133

Post by reilly3000 »

pojzon wrote: post #69
kevan wrote: post #57

Earlier quoted context omitted.

Have you checked out CDK or Pulumi? CDK still has a few warts but overall I've been pretty happy with it. Haven't used Pulumi but from chatting with friends it sounds like it has a similar feel as CDK but supports multi-cloud like Terraform.

Cdk is compiling into CF template. And Pulumi is using Terraform providers under the hood. Writing infra in imperative style can cause ALOT of unseen issues when developers start adding IFology or Design Patterns..

Pulumi also has a newer iteration that uses provider APIs directly. A pain point has been that terraform provides tend to lag significantly with platform APIs, or just miss some functionality entirely.

Re: Terraform should have remained stateless

#134

Post by ealexhudson »

pojzon wrote: post #69
kevan wrote: post #57

Earlier quoted context omitted.

Have you checked out CDK or Pulumi? CDK still has a few warts but overall I've been pretty happy with it. Haven't used Pulumi but from chatting with friends it sounds like it has a similar feel as CDK but supports multi-cloud like Terraform.

Cdk is compiling into CF template. And Pulumi is using Terraform providers under the hood. Writing infra in imperative style can cause ALOT of unseen issues when developers start adding IFology or Design Patterns..

Pulumi can use TF providers but in general has custom providers, as I understand it - generally you would not be using the TF provider for most deployments.

Re: Terraform should have remained stateless

#135

Post by michaelsalim »

franzwong wrote: post #132

If you use Terraform, you should only update your infrastructure through Terraform and persist the state in a shared place (e.g. S3 versioning). I see people having hard time when they use both AWS CLI, AWS console and Terraform.

This is my big pain point with Terraform. Sometimes I forgot to update only through Terraform. Especially when it's trivial to do the change through UI but not necessarily the config.

I wish Terraform could automatically detect the change and convert it into code.

Re: Terraform should have remained stateless

#136

Post by robertlagrant »

I think the best thesis for this is decentralisation. The stateless approach only works if this one tf file (or set of files) manage(s) the whole world.

As soon as you get to multiple teams managing (say) AWS infra, you can't infer that a resource present in infra but not in tf file means a resource should be deleted.

Re: Terraform should have remained stateless

#138

Post by ciceryadam »

tragomaskhalos wrote: post #128

Terraform has to have state, for the reasons outlined by other commenters. But, it is undoubtedly a pain in the arse in practice - invariably someone else is doing a change on a branch but has already applied it to the development infra using the shared state bucket, which then pollutes it for everyone else as you don't have those changes so your applys will now want to undo them. As a first timer with this stuff, I…

We use a single a single tf state per Google project. Instead of slicing up the state into multiple substates, we use modules as much as possible, and use "-target=module.module_name" to test our branches.

Re: Terraform should have remained stateless

#139

Post by sitkack »

benreesman wrote: post #130

Given that there are well over 100 comments in this thread it’s possible that someone already mentioned this, but for people who are short-staffed but highly adventurous NixOS has an interesting take on all this. There’s even a Terraform binding called Terranix that isn’t too bad. It’s a real journey and not for people under short-term time pressure, but of all the pain-in-the-ass things I’ve learned in computing ove…

interesting https://terranix.org/

https://terranix.org/documentation/terranix-vs-hcl/

Re: Terraform should have remained stateless

#140

Post by FooBarWidget »

Faaak wrote: post #122
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…

TF noob here: is it not possible to store a "managed by terraform" annotation on the resources ? Or are not all resources able to store labels (extreme example: terraform-spotify plugin)

Many resources don't support abitrary metadata.
Post reply on HN