changes to module resources should be more informative

[ketzacoatl]

Apologies if an existing issue is out there on this one.. I looked around a bit but could not find one.

When using modules to encapsulate the details of one or more resources, terraform plan doesn't tell you much of anything about what will change in the module:

~ module.stash
    1 resource(s)

In this case, Terraform will actually destroy an AWS instance on me, though I have no idea that is going to happen until I run terraform apply. Worse yet, I generally rely on the details provided in terraform plan to find out how to work around terraform wanting to destory a resource on me.

I have been looking forward to re-using code through modules, but in my initial tests, I do not think I cannot rely on modules until I can rely on terraform plan to be more clear about what it wants to do to change a module.

See here for a similar comment about how this can be problematic.

[mitchellh]

/cc @eukaryote

I think we should change the ~ to simply be -/+. I know @eukaryote wanted module-depth=-1 to be default, but this quickly gets out of hand for the plan and we intended modules to mostly be black boxes. I think the issue is that ~ isn't expressive enough: we should just show the worst case.

[ketzacoatl]

@mitchellh I'm glad you agree. I think the one last bit of feedback I have: IMHO, modules as black boxes is fine, but I really need to know what in a module is contributing to Terraform wanting to recreate my instances.

I do not see how it is possible to use Terraform for managing production resources if you are always working to keep the tool from rm -rf'ing your production resources. Maybe I am using Terraform in completely the wrong way? In this case, I have just started using modules, and I'm pretty sure I am on the right track with what I'm doing.. but I don't see how the interface is usable without being more vocal about what and why the module needs changes.

[eukaryote]

I think changing '~' to the worst case in the module is a good improvement.

I still think there's merit in making the default output more informative though. Maybe -1 is not feasible if there are many people who have deeply nested modules, but perhaps 1 would be a better default than 0?

I'd also be fine with specifying a default -module-depth in some terraform rc file somewhere as well. I just don't want to have to explicitly supply the parameter every time I invoke terraform, which I have to do currently since all my resources are in top-level modules that are referenced from my main terraform config.

[ketzacoatl]

+1 on flexibility through default module depth, or something configurable. I don't mind supplying the parameter on the command line, I use aliases for this sort of thing.

[blakeblackshear]

+1 Informative plans are the reason I use terraform instead of cloudformation.

[blakeblackshear]

I have decided to stop using modules until this is worked out.

[gamename]

Guys, any updates to this? Our terraform topologies are proliferating and they are harder and harder to maintain without modules.

[phinze]

Hey folks - sorry for the lack of updates on this. I just checked back in with the core team and we've decided to update the module-depth behavior to expand all modules by default, which I believe addresses the concern of this thread.

#4763

Closing this since the PR is on its way in. Feel free to follow up if there's anything further to discuss!

[ketzacoatl]

Thank you, this is great!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.