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

231–240 of 329 posts

Re: Terraform should have remained stateless

#231

Post by InvaderFizz »

jillesvangurp wrote: post #150
raffraffraff wrote: post #117

Earlier quoted context omitted.

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…

Sounds like a plan for a next generation cloud provider. They all have internal state about your account and what's running there; they just don't really expose it in a standardized way. Nor do they provide standardized ways to update that (other than a lot of cli tools and REST APIs). We keep coming up with these layers of abstractions around stuff that at the bottom is essentially already stateful but just not in a…

Oracle Cloud does this. You can export Terraform for a Compartment[0] (think LDAP OU).

This is how we do our initial terraform for new projects. We build up what is missing by hand, then export the terraform to save time and effort in building our own internal templates. We throw away most of it, but it is very useful for not having to look up how every aspect is named and what options are needed.

0: https://docs.public.oneportal.content.oci.oraclecloud.com/en...

Re: Terraform should have remained stateless

#232

Post by jen20 »

nathants wrote: post #70
taeric wrote: post #45

Earlier quoted context omitted.

Sorta. Creation is only easy if you know what the expected state is. Did you just create a new table, or was it already created? This is especially hard when you /want/ table names that are not stable.

using names to uniquely identify infrastructure is very convenient and how most of aws already works. why not take advantage of that instead mapping name to uuid via state? in what scenario are non-stable infrastructure names useful?

It certainly isn’t how “most” of AWS works. Nothing makes the name tags for important APIs like VPC or EC2 even exist, yet alone be unique. They use provider-assigned IDs instead.

Re: Terraform should have remained stateless

#233

Post by jen20 »

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.

Next question: what if your database is managed by a separate team in the same account? Just delete it eh?

Re: Terraform should have remained stateless

#234

Post by boesboes »

pst wrote: post #220
boesboes wrote: post #155

Personally I think the custom dsl’s are a bigger issue. I spend a lot of time wrangling tf to have reusable, configurable modules. The more i use tf, the more i think it would be better to remove _all_ dynamic features and use a real language to generate tf configs as flat, static files.

Yes, conditionals and loops in TF are limited and have various annoying and surprising edge cases. But if something is hard to do with the Terraform DSL it's usually a good idea to reconsider if it is really something that one should be doing. We want infrastructure automation to be boring and just work. The risk with general purpose programming languages is that people will always find a way to outsmart themselves.…

Yeah there is definitly something to be said for having a limited DSL. I feel though the language as-is, has a bit to much dynamic features that kinda half work and then give you completly useless error messages. But tbf, it has gotten alot beter with recent versions.

But to explain where I'm coming fromm, this is something I ran into recently:

this breaks and returns null if http is not set: lookup(each.value.http, "port", 8080)

So I need to do this to make it work: coalesce(lookup(each.value.http, "port"), 8080)

Not a huge deal, but just one of these many things over the years where I think don't reinvent the wheel.

Re: Terraform should have remained stateless

#235

Post by lloydatkinson »

I am a big fan of Azure ARM/Bicep. I can’t imagine needing to deal with stateful IaC. Perhaps Azure doesn’t need to do that because it’s able to provide guarantees about their own platform or something.

The actual infrastructure and its configuration is the state. It does a diff to see what needs changing.

Re: Terraform should have remained stateless

#236

Post by giaour »

cheradenine_uk wrote: post #116
janosdebugs wrote: post #107

Earlier quoted context omitted.

I think there is a misunderstanding: when I'm talking about "name" I mean the "name" stored by the cloud provider, which is typically (arbitrarily) chosen as the idempotency key by stateless implementations. When you change the name of the resource that will, obviously, break the connection, that's a big no-no when writing Terraform code.

Sure, but isn't the artcle suggesting tags rather than the name / ID ? One problem, as mentioned in a sibling comment, is if you don't have state then how do you know a resource has been deleted? One other option might be a system that compares the "desired state" from the previous version of the config. That might be an interesting approach - keeping a history of config. But that is, of course, state :) I use TF a b…

Bicep and Azure Resource Manager (ARM) are able to dispense with state only because every Azure resource is required to be individually addressable and to report its state in a consistent way, and each resource is expected to support fully idempotent creation operations. The state information is still there, but it's stored on the resource itself.

Bicep/ARM still has issues with resource deletion, though. The default deployment behavior is to ignore resources that aren't described in a deployment template, so if you remove a VM from your template and redeploy, the VM will keep running until you manually delete it. There are a couple ways around this issue, but they all rely on having state external to the resource itself.

Disclaimer: I work on Bicep/ARM and think it's pretty great, but it's not perfect.

Re: Terraform should have remained stateless

#237

Post by [deleted] »

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?

[deleted]

Re: Terraform should have remained stateless

#238

Post by vlunkr »

devit wrote: post #209
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).

These arguments are just going in circles but here's why: You can't store metadata on every object in every provider, and often, resource names are restrictive in length and allowed characters. And what if something needs deleted? Now every time you run terraform you need to list every type of object the provider offers and check tags, that's a huge waste of time and bandwidth.

Re: Terraform should have remained stateless

#239

Post by giaour »

lloydatkinson wrote: post #235

I am a big fan of Azure ARM/Bicep. I can’t imagine needing to deal with stateful IaC. Perhaps Azure doesn’t need to do that because it’s able to provide guarantees about their own platform or something. The actual infrastructure and its configuration is the state . It does a diff to see what needs changing.

Azure has some pretty strict internal requirements around resource creation that make this possible. Every service must provide a "Resource Provider"[0] API that supports idempotent creation operations and standardized query patterns for read operations. Whether you create a resource through an ARM template, in the portal, or via the CLI, it's going through the same unified API surface.

So, there is definitely still state, it's just stored centrally.

[0]: https://docs.microsoft.com/en-us/azure/azure-resource-manage...

Re: Terraform should have remained stateless

#240

Post by hamandcheese »

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?

So state, but probably way slower and varies from cloud to cloud.
Post reply on HN