[JohnMakin]

been using terraform heavily for 5 years and have hacked together modules and custom providers for various ad-hoc things.

One of the things that has always really frustrated me about terraform is that it seems to go out of its way to make you do things in a very annoying, inconsistent way. Part of this is necessary due to the nature of the provider ecosystem, you can't guarantee consistency across providers - and I won't burden this post with my gripes about inconsistencies and annoyances within providers, such as the AWS provider.

Really though the interface has always been terrible (IMO). Stuff like iterating through a nested map using a for loop, which is trivial in most languages, is annoying and obtuse to the point of comedy. God help you if this map contains mixed types. Novices have trouble picking it up in general. It's very easy to start a project that sprawls completely out of control, and there doesn't seem to be a standard at all as to how to organize projects/code, so each terraform project I inherit is wildly different and has its own seemingly unique pain points.

A lot of this has gotten better over the years with QoL improvements within terraform itself - but really, as a developer, I've gotten more than a little tired about the hubris that Hashicorp shows with some of the stuff around the terraform ecosystem. Features that people beg for routinely get told by maintainers that they will not be doing that because reasons or because "it's not possible" (such as dynamic provider blocks). OpenTofu is already tackling many of the gripes and feature requests I've had over the years and are doing so eagerly and have some heavy hitters behind it.

Terraform is good, but it was always going to be vulnerable to competition - It's basically just a state-based wrapper around cloud API's. A great idea, but easy to duplicate. I don't know what they were thinking trying to put this behind a walled garden when they could have used it to get people into the hashicorp ecosystem and sell their other enterprise products.

[hamandcheese]

What really grinds my gears is how hard it is to refactor terraform code. Put something in a module, but want to move it elsewhere? Get ready for pain.

I've been using terranix, which uses nix to generate a tf.json file, and oh my god is the experience night and day. I can make functions! I can refactor! And if it's a pure refactor, there is nothing to apply.

[cdchn]

How does terranix help you with the "move a resource from a module to somewhere else" problem?

[hamandcheese]

It helps because you don't use terraform modules at all, any abstraction you need can be done in nix before tf.json gets written.

[JohnMakin]

I know many people find it painful but isn't this fairly simple with "terraform state mv?"

my process is roughly:

comment out the resource in the module, run a plan -> get output like:

"module.foo1.aws_resource.bar will be deleted"

Then copy my resource in source to module.foo2.aws_resource.bar, the command becomes:

terraform state mv module.foo1.aws_resource.bar module.foo2.aws_resource.bar

I guess this might be harder if you're using upstream "official" modules, but I avoid those like the plague.

[rjbwork]

You don't even need to do state mv anymore. They added the `moved` block a while ago. You can then delete it from the source after your apply at your leisure.

[hamandcheese]

"Every change requires two PRs that aren't in the same terraform run" still way way way too much mental overhead just to do a simple refactor.

[hamandcheese]

Yea, there are tools to work around it, but the fact that a pure refactor would impact terraform state at all is the design flaw in my eyes.

Suddenly, just to refactor the source in a way that shouldn't touch any resources, you have to have be able to mutate the terraform state. (Or use the more recently introduced moved blocks, which is still quite a big kludge).

This means any kind of broadly sweeping refactor (which might impact many different state files) is really hard.

[nprateem]

If OT want to win all they need to do is actually make it possible to debug the code.

[toolslive]

It ain't Infrastructure As Code if you can't put a break point.

[fishnchips]

Co-founder of OpenTofu here.

Second that. One of my colleagues is working on adding proper tracing to the OpenTofu codebase, to help understand the exact cause of failures.