Hacker News Reader

Comment by hamandcheese | Hacker News Reader

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.

View on HN

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

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.

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.

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.

"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.

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.

Reply on news.ycombinator.com